OAuth 2.0 is an authorization framework.
It's for the situation when you want to ask a user for permission to access some resources (call an API) on their behalf.
It allows a user to delegate access from one service where they have an account to a different service.
This means that, as an API implementor offering 3rd-party access, I don't have to care about the user's login credentials. I don't even necessarily have to care about the type of credentials that they use.
OAuth only really helps if the user needs to choose to accept or deny permissions. Some examples of when this happens:
- The user is actually your user. They type their username and password into your website so that it can talk to your own API. OAuth provides the resource owner password credentials grant for this situation, but you should probably just use Bcrypt.
- If you, as an API owner, decide to trust someone to make calls to you, and you don't think you need to ask your user for permission. In this case, just generate a secret and give it to that someone.
The amount of access delegated using OAuth is controlled using scopes.
OpenID Connect is a protocol for authentication built on top of OAuth 2.0. In this case, the thing you are delegating is your logged-in identity, which usually means a verified email address.
This is how you make a login with AmaGooFaceSoft button.
The lead specification writer for OAuth 2.0 took his ball home, claiming that, because of the involvement of enterprise developers in the working group, the specification had become complex and vague.
It's therefore very unlikely that different implementations will be interoperable. Furthermore, it's quite easy to create an insecure implementation.
The objections here seem valid.
Authorization provided using tokens
The user-operated client program exchanges tokens (usually JSON Web Tokens) with various parties.
- Id token (OpenID Connect)
- claims that the bearer has authenticated as a person, with some specific details about who they are. The consumer of this token is an authorisation server. You can also use it to display personallized greetings to the user.
- Access token (OAuth 2.0)
- claims that the bearer is authorized to access some functions of an API. This token may have some user information baked in, but it shouldn't leak personal details. The consumer of this token is a specific resource provider.
- Refresh token (OAuth 2.0)
- a way to get a new access token.
These are all signed, and you need to verify the signature. You should also check the expiration.
Lastly, there is be a state parameter which you set in your request, and should come back in the response. You can use this to prove that this token was sent to you in response to the known request that you made.
Machine to machine authentication
This is when the application is also the resource owner. We use client credentials grant.
We use our client it to ask for an access token, and then send it in API requests.
The user usually has to authorize specific client ids.
Server side authentication
authorisation code grant
- Browser visits resource owner server:
- User agrees to requested permissions.
- Resource owner server page redirects browser to your web app, including an Authorisation code.
- Client-side web app code sends Authorisation code to backend server.
- Backend visits authorisation server
/oauth/tokenURL, passing Authorisation code. Gets back access token, and maybe other tokens too.
- Backend calls APIs and sends result to browser.
In practice, the resource owner server and the authorisation server are likely the same?
There's an implementation guide for NodeJS here: https://auth0.com/docs/quickstart/webapp/nodejs.
Client side authentication
This is less good. You can use implicit grant, but the OAuth 2.0 website says not to.
- Browser visits authentication server:
- User agrees permissions.
- Authentication server redirects browser to your web app. Access token is included in the hash fragment.
When authorizing, include
prompt=none — as in —
SAML is a protocol for single-sign on for enterprise organisations.
A standard use is if you have a lot of programs on an intranet, and want a per-employee login for all the programs.
Technically you could probably do the same as with OAuth though? Not quite clear. Some people on the web say no, some say yes.
Auth0 is a company which provides OAuth 2.0 and OpenID Connect support, including delegation to other OpenID Connect providers.
Their main selling points are lots of customization.
They offer lock, which is a lock screen widget for the web.
Another product they provide is guardian, which is multi-factor authentication.
This provides both authentication and authorisation.
It's an implementation of SAML 2.0, but it also provides OAuth 2.0.