Search code examples
oauth-2.0

Which OAuth 2.0 flow to use?

I have read rfc6749 and https://auth0.com/docs/authorization/which-oauth-2-0-flow-should-i-use but I couldn't seem to find the flow that's exactly for my use case.

There will be a native app(essentially a GUI) that will spin up a daemon on end user device. The daemon will try to call internal APIs hosted by the backend. The internal APIs don't need to verify the user identity; but it's preferred that the device identity can be verified to some extent. There will be an OAuth authorization server in the backend to handle the logic. But I couldn't identify which is the correct flow to use for this case.

Originally I thought this is a good fit for client credentials grant type. But then I realized that this might be a public client but client credentials is supposed to be used for confidential clients only.

I then came to find out about authorization code with PKCE flow. This seems to be the recommended flow for native apps but it doesn't make much sense to me as there will be redirects and user needs to interact but the APIs that will be called is supposed to be internal and user shouldn't know about these back channel stuff at all. Also the resource owner should be the same as the client in this case, which should be the machine not the user.

So which flow should I use?

Thanks a lot for the help!

Solution

  • Client Credentials feels like the standard option but there are a few variations:

    SINGLE CLIENT SECRET

    This is not a good option since anyone who captures a message in transit can access data for any user.

    CLIENT SECRET PER USER

    Using Dynamic Client Registration might be an option, where each instance of the app gets its own client ID and secret, linked to a user.

    The Daemon then uses this value, and if the secret is somehow captured in transit it only impacts one user.

    STRONGER CLIENT SECRETS

    The client credentials grant can also be used with stronger secrets such as a Client Assertion, which can be useful if you want to avoid sending the actual secret.

    This type of solution would involve generating a key per user when they aughenticate, then storing the private key on the device, eg in the keychain.