Consuming own API for web app - Authentication process with OAuth2

Question

Overview

I am currently in the process of creating an API for an image sharing app that will run on the web and sometime in the future, on mobile. I understood the logi

Answer 1

Your approach seems workable.

Oauth2 has 4 main parts:

• Resource Server (your API)
• Resource Owner (end user who has data on the resource server)
• Authorization Server (gets authorization and issues tokens)
• Client (your web app - and future apps)

Bear in mind with the Client Credentials grant, the token you are issued probably won't have any user context. So if your API endpoints rely on a user identifier / resource owner being contained within the token, then you will need to code around that for this type of token.

If you do need the token to have some resource owner context for your API, and your web application happens to be your identity provider, then then you could use the resource owner password grant which will give you a token and refresh token in the context of a resource owner/user.

The Authorization code grant is fine providing your future API consumers are web apps (i.e. run on servers). If you plan to allow mobile/native apps to use your API then you should consider allowing the Implicit Grant in your Authorization Server.

If your API doesn't have end users and each client has varying access to the API depending on what app it is, then you can use the client-credentials grant and use scopes to limit the API access.

EDIT

So my API must be accessible to the world with guest access (non logged in people can upload, for example) and to registered users. So when a registered user uploads, I obviously want the user to be sent along with the request and attach that user to the uploaded image

To achieve this your API upload endpoint could process Oauth2.0 Bearer tokens but not be dependent on them. e.g. the endpoint could be used by anyone, and those who supply an access token in the headers will have their upload associated with their user context obtained by the API from within the token. You could then make other endpoints dependent on the token if required.

EDIT based on comments

the registration process itself will use the client credentials grant, correct?

I don't think the registration process itself should be a resource protected by Oauth. Ideally registration should be handled by your identity provider (e.g. google, facebook or your own user membership database). One of the plus things about Oauth2.0 is that it removes the need for APIs to have to do user admin stuff.