Best authentication/setup flow for third-party Alexa skill using Emby

[MarvinB 4]

Hi everyone,

I’m building an Alexa skill called Ear Wax that plays music from an Emby server.

For my own server, the skill works using: - Emby host/DDNS - Emby user id - Emby API key/token

Now I’m preparing beta/public testing and I want each user to connect the skill to their own Emby server. The goal is a simple setup flow:

1. User enables/links the Alexa skill.

2. User enters or selects their Emby server.

3. User signs in with their Emby credentials.

4. The skill receives/stores a server URL, Emby user id, and access token.

5. The skill uses that token for normal Emby API calls and audio playback.

I am trying to avoid asking users to manually create API keys or speak long credentials to Alexa.

 

Questions:

1. Is there a supported/recommended API flow for third-party apps to authenticate a user against their Emby server and receive an AccessToken?

2. Should I use `/Users/AuthenticateByName` directly against the user’s server?

3. Is Emby Connect available/recommended for third-party apps to let users sign in by email and select their server?

4. Is the Emby Connect PIN flow documented or supported for third-party apps?

5. For a public Alexa skill, what is the preferred way to store/use tokens securely?

6. Are there any restrictions or best practices for third-party apps using Emby user tokens for music playback?

I’m happy to follow the recommended supported route. I just want to avoid building a fragile setup process if Emby already has a proper flow for this.

 

Thanks.

[Luke 42555]

Quote

1. Is there a supported/recommended API flow for third-party apps to authenticate a user against their Emby server and receive an AccessToken?

Just the regular api.

Quote

2. Should I use `/Users/AuthenticateByName` directly against the user’s server?

If you intend to do local sign-ins against a server, then yes.

Quote

3. Is Emby Connect available/recommended for third-party apps to let users sign in by email and select their server?

It's really up to you and whether you want to support dual login methods or not. It does make things more complicated and can cause users to get confused, so I would suggest picking one or the other and just go with it say the other way is unsupported. This is one of those cases where you will get punished for trying to do too much.

[MarvinB 4]

@Luke thank you