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

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).

Answer 2

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 3

iandayman's answer has lots of good information, but I think a narrower more specific answer might help you.

So for starters, the client credentials grant is not for you. If we look at the OAuth2 spec, the client credentials grant is for

when the authorization scope is limited to the protected resources under the control of the client ... when the client is acting on its own behalf

This is not right for you for two reasons.
Firstly there are no protected resources under the control of your client. All resources you are accessing are either unprotected (non-logged in people uploading) or are under the control of an end user. Further, you cannot keep secrets (such as the client secret) in the browser; any user of your application could just use the developer tools of the browser to view and compromise the secret.
Secondly, as I mentioned, the client is never acting on it's own behalf. It's always acting on behalf of a user who may or may not be logged in.

You want the resource owner password credentials grant.
When a user is not logged in (like you mentioned for uploads) you just have no authorization. When a user logs in, you send their credentials to the authorization server. If the password matches the username, the authorization server makes a token and persists a mapping from that token to the user and returns the token. Then every time your client makes another request for a logged in user, you put that token in the Authorization header. On the back end you say "if there is a token in the authorization header, find out which user it corresponds to, and associate them with this upload (or check if they're allowed to upload at all)".

How does user registration work? Simple, you post some user object like

name: jim beam
username: jimb
password: correct horse battery staple

to your user creation endpoint (POST /users or something). You generate a salt and hash the password, and then store the user's information along with the salt and hash in the database. There is no authorization on this endpoint whatsoever.

Hopefully this is more what you are looking for.