Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does 2-legged oauth work in OAuth 2.0?

In OAuth 1.0, 2-legged is pretty easily: Simply send the request as usual and omit the access_token header.

Things seems to have changed in OAuth 2.0 (drastically, as I found out today :)). In OAuth 2.0, the request no longer has headers such as the nonce, consumer key, timestamp etc. This is just replaced by:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh 

I understand how 3 legged authorizations work in OAuth 2.0 and the application flows. But how does 2-legged work in 2.0? Is it possible to design an API that can support both 2-legged and 3-legged OAuth 2.0?

I have been searching for information regarding this, but I have been finding a lot of stuff on 2-legged for 1.0 and almost nothing for 2.0.

like image 395
F21 Avatar asked Jan 10 '13 03:01

F21


People also ask

What is OAuth What are the differences between 3 legged and 2 legged OAuth?

A typical OAuth flow involves three parties: the end-user (or resource owner), the client (the third-party application), and the server (or authorization server). So a 3-legged flow involves all three. The term 2-legged is used to describe an OAuth-authenticated request without the end-user involved.

How does OAuth 2.0 authentication work?

It works by delegating user authentication to the service that hosts a user account and authorizing third-party applications to access that user account. OAuth 2 provides authorization flows for web and desktop applications, as well as mobile devices.

How does OAuth2 2.0 work in REST API?

In OAuth 2.0, the following three parties are involved: The user, who possesses data that is accessed through the API and wants to allow the application to access it. The application, which is to access the data through the API on the user's behalf. The API, which controls and enables access to the user's data.

Is oauth1 OAuth2 compatible?

OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol. OAuth 1.0 was largely based on two existing proprietary protocols: Flickr's authorization API and Google's AuthSub.


2 Answers

After lots of research, I discovered that client_credentials grant type is for this scenario. Once you punch this term into google, you can find loads of very helpful resources.

This is the normal flow for 3-legged OAuth 2.0 (we want the user to sign in):

Assume we have the following endpoints in our app for authentication:

/oauth/auth  /oauth/token 

Normally (for authorization code grant), we direct the user to /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Then upon authentication, the user is redirected to mysite.com/blah?code=somecode

We then get somecode and exchange it for a token using /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

We can then use the token to make calls.


This is the application flow for client_credentials to implement 2-legged OAuth 2.0, which is markedly simplier:

  • In this approach, we do not need to perform any authentication.

  • We simply POST to /oauth/token with the following form data:

     grant_type=client_credentials&scope=view_friends 

Note that scope is optional. The endpoint then directly returns an access token for us to use (no refresh token is provided). Since no refresh token is provided, when the token expires, you will need to reauthenticate and ask for a new one.

This leads to the following caveats:

  • Use this only for (very very) trusted applications such as internal applications.
  • You need to devise your own way to authenticate. For instance, the RFC's example uses basic auth.

Another solution is to use JWT (JSON web tokens) like the google OAuth API. It is a very complicated process, but there exists numerous libraries for generating your JWT. You then post the following form data (url encoded of course):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt 

This is posted to /oauth/token to get your token.


As for the question of whether you can create an API that supports 2-legged and 3-legged OAuth 2.0, Yes, it is possible.

Then /auth endpoint is only used when users need to authenticate against the service.

In the /token endpoint, simply check the value of grant_type in the GET parameters for urn:ietf:params:oauth:grant-type:jwt-bearer if using JWT or client_credentials for client_credentials.

Note that when generating the client_id and client_secret to give to the user, if you are supporting multiple grant_types, ensure that you have a database column to store what type of grant type the id and secret was generated for. If required to have multiple grant types per user, generate a different set of credentials for each grant type.

like image 140
F21 Avatar answered Oct 04 '22 06:10

F21


You can also check out Google's implementation of 2-legged OAuth2 (I believe this documentation has been published only recently).

The Google Drive SDK delegation docs should also help understanding Google's 2-legged OAuth2 implementation.

like image 24
Miguel Andres Avatar answered Oct 04 '22 07:10

Miguel Andres