In this blog we will discuss how OAuth works. Our focus would be on OAuth 2.0. There are many articles on the internet that talks about OAuth 1.0.
How OAuth 2.0 is different from OAuth 1.0
OAuth 1.0 involved certificates so if you were to code for OAuth 1.0 you would have to know about how to sign the requests using signature methods like HMAC-SHA1 or RSA-SHA1 etc. OAuth 2.0 is much simpler. It relies on SSL instead of signatures.
OAuth 1.0 had only one flow for authentication. OAuth 2.0 defines multiple flows or client profiles for handling authentication e.g. web application, user agent and native.
Actors in OAuth 2.0
Following are the important roles in OAuth 2.0
a. Resource Owner – Person whose data/information is to be shared between two applications.
b. Resource Server – Application that hosts user’s data/information.
c. Client Application – Application that needs to access data from the resource server on the resource owner’s behalf.
e.g. let’s assume that I want to use friendfeed to browse the photos that I have uploaded to my Flickr account. In this case, I become a resource owner, Flickr becomes a Resource Server and FriendFeed becomes a Client Application.
Getting Ready for OAuth
Before a client application can start accessing resources on the resource server, it needs to register itself with resource server. This registration is a one time activity and once registered client application gets a client id and secret.
During registration, client application also provides a redirect uri to resource server. This redirect url is used during the OAuth authorization flow.
In the above example, FriendFeed would have registered it with Flickr and obtained client id and secret from Flickr.
OAuth authorization flow
Let’s look at Oauth authorization flow for a web application profile.
Continuing with the above example, assume that I am trying to use firendfeed to access my photos that I have uploaded to my Flickr account. At this time FriendFeed will check if it has an access token in order to get photos from Flickr on my behalf. If access token is not found then FriendFeed would initiate OAuth flow which would typically have following steps.
Step 1: User accesses client application.
Step 2: Client application redirects to resource servers authentication page.
Step 3: Resource server authenticates the user and then obtains user's authorization for the data that client application is trying to obtain from the resource server on the user's behalf.
Step 4: The Resource server generates the authorization code and redirects to client application including authentication code. Resource server uses the redirect url that client application provided during registration.
Step 5: Client application sends a request for access token. Client application includes the client id and secret in this request.
Step 6: The Resource server sends the access token. This access token comes with an expiry date.
Step 7: The Client application accesses the services provided by the resource server to access user’s data as long as access token is not expired.
Here we looked at the flow for web application profile. The flow would vary slightly for other profiles.
How OAuth 2.0 is different from OAuth 1.0
OAuth 1.0 involved certificates so if you were to code for OAuth 1.0 you would have to know about how to sign the requests using signature methods like HMAC-SHA1 or RSA-SHA1 etc. OAuth 2.0 is much simpler. It relies on SSL instead of signatures.
OAuth 1.0 had only one flow for authentication. OAuth 2.0 defines multiple flows or client profiles for handling authentication e.g. web application, user agent and native.
Actors in OAuth 2.0
Following are the important roles in OAuth 2.0
a. Resource Owner – Person whose data/information is to be shared between two applications.
b. Resource Server – Application that hosts user’s data/information.
c. Client Application – Application that needs to access data from the resource server on the resource owner’s behalf.
e.g. let’s assume that I want to use friendfeed to browse the photos that I have uploaded to my Flickr account. In this case, I become a resource owner, Flickr becomes a Resource Server and FriendFeed becomes a Client Application.
Getting Ready for OAuth
Before a client application can start accessing resources on the resource server, it needs to register itself with resource server. This registration is a one time activity and once registered client application gets a client id and secret.
During registration, client application also provides a redirect uri to resource server. This redirect url is used during the OAuth authorization flow.
In the above example, FriendFeed would have registered it with Flickr and obtained client id and secret from Flickr.
OAuth authorization flow
Let’s look at Oauth authorization flow for a web application profile.
Continuing with the above example, assume that I am trying to use firendfeed to access my photos that I have uploaded to my Flickr account. At this time FriendFeed will check if it has an access token in order to get photos from Flickr on my behalf. If access token is not found then FriendFeed would initiate OAuth flow which would typically have following steps.
Step 1: User accesses client application.
Step 2: Client application redirects to resource servers authentication page.
Step 3: Resource server authenticates the user and then obtains user's authorization for the data that client application is trying to obtain from the resource server on the user's behalf.
Step 4: The Resource server generates the authorization code and redirects to client application including authentication code. Resource server uses the redirect url that client application provided during registration.
Step 5: Client application sends a request for access token. Client application includes the client id and secret in this request.
Step 6: The Resource server sends the access token. This access token comes with an expiry date.
Step 7: The Client application accesses the services provided by the resource server to access user’s data as long as access token is not expired.
Here we looked at the flow for web application profile. The flow would vary slightly for other profiles.
No comments:
Post a Comment