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 logical parts of API building, but I'm still struggling to meet my own requirements for the authentication part.

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

---

Authentication via OAuth2 - Implementation

I have understood that OAuth2 is the way to go when it comes to API authentication, so I am going to implement this one, but I'm really struggling to wrap my head around on how to handle my situation. I thought of using the client credentials grant and generating only one set of credentials for my web app, and having it send requests to the API with its client secret to obtain the access token and let users do stuff. The user registration process itself would be handled with this grant.

But what about when the user is registered and logged in? How do I handle authentication now? Would this require another grant to take over? I was thinking of doing some authorization process during user signin, to generate a new access token. Is this approach wrong?

---

What I need help with

I need your input on how to handle the authentication flow correctly for my case. This two-way authentication process might not be what I need, but it is the way I've understood it. I would highly appreciate your support.

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.

Answer 2

You don't really need oauth to authenticate to your own API.

OAuth2 is usefull if you want another application to access your API.

Let me explain a little bit how OAuth2 works:

• A Client (application) wants to use your API so you give him Client credentials (client_token and client_secret). And you set in your database a set of redirect locations that the client can use.
• The Client needs the user authorization for him to use your API in the user's behalf. So, the client sends the user to a url on your site (with the client_token, scope the client needs [you define the meaning of the different scopes], a redirect uri and a response_type [oauth2 defines different response_type but let's focus on 'code'])
• The user logs into your site and accepts to give access to the client to your API on the user's behalf. When the user accepts this you'll generate a grant (the grant contains info of the user, the credentials requested [scope] and the client who can 'claim' the granted access).
• The user is then redirected to the redirect_uri that the client requested (When the client sent the user to your auth site) and in the URL parameters you'll include the grant code (it's just an id).
• At this stage, the client will make a request to your API providing the grant code, his own client_token, his client_secret and the grant_type (authorization_code) and he will get on the response the following: an authorization_token, refresh_token, token_type (for this case, Bearer), expires_in (expiration time in seconds) and the scope.
• After all this the client will be able to make requests to your API on the user's behalf using the access_token privided until the token expires. Once the token expires the client will have to request for a new access_token using the refresh_token (instead of the authorization code).