-
Notifications
You must be signed in to change notification settings - Fork 11
[Blog] OAuth Vs OpenID What, Why and When?
I see a blatant misconception, confusion and lack of understanding of the two widely used open standards for web: OAuth and OpenID, that I am compelled to write this blog and hopefully clear some doubts.
Taken directly from the official OpenID website
OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.
With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password, so you don’t need to worry about an unscrupulous or insecure website compromising your identity
Have you ever decided not to use the services on a website just because they were asking you to create a profile, choose a username and password, validate your email, and so on? Well, you are not alone. Creating thousands and accounts and remembering username/password on each of them is a nightmare, not just from a manageability perspective but also from security. Most users will end up choosing the same username/password for each account. So when one of their accounts gets hacked it is easy enough for an attacker to hack other accounts. Even for the websites, managing user accounts introduces a lot of overhead. Not only they must allocate resources for managing user data but also ensure their passwords are stored securely. It seems like going through a lot of trouble, considering that most websites are only interested in basic user information such as their first name, last name, date of birth and email address - something that can be easily inferred from user's profile on social website such as Google, Yahoo, etc.
OpenID is a win-win for everybody. Users can use their existing accounts without sharing their password with third-party websites. They can choose what information they would like to share. The websites don't manage user accounts, they don't have to validate email addresses and can concentrate on the business purpose they are serving.
Let's assume your OpenID provider is Google.
This consists of the following steps. 1. The web application asks the end user to log in by offering a set of log-in options, including Google Apps accounts.
2. The user selects to sign in using a Google Apps account.
3. The web application performs discovery as defined in the documentation to find the location of the XRDS document.
4. Google returns an XRDS document, which contains the Google Apps (hosted) domain endpoint address.
5. The web application sends a login authentication request (optionally with OAuth parameters) to the provided endpoint address.
6. This action redirects the user to a Google Apps account Federated Login page.
7. The user signs into their Google Apps account. Google Apps then displays a confirmation page and asks the user to confirm or reject a set of authentication requests by the web application. If the web application is using OpenID+OAuth, the user is also asked to approve access to a specific set of Google Apps services.
Note: In some circumstances, the login step or the approval step (or both) may be skipped. 8. If the user approves the authentication, Google returns the user to the web application and supplies a persistent, opaque identifier that the application can use to recognize the user. For OpenID+OAuth, an authorized request token is also returned.
9. The web application uses the Google-supplied identifier to recognize the user and allow access to application features and data. For OpenID+OAuth, the web application uses the request token to continue the OAuth sequence (at step 7) and gain access to the user's Google Apps services.
Although this workflow is somewhat Google specific but the same applies for any other OpenID provider.
OAuth is an open standard for authorization. It allows client applications to request access to resources hosted on a resource server on behalf of resource owners.With regards to OAuth it is important to understand following roles:
Resource
A resource can be anything from user information, pictures,files,
services, etc.**
**
Resource Server
The server hosting resources that are owned by the user and protected by OAuth.
Resource Owner
Typically the user of an application who owns the resources. He is the one who can grant access to client application for accessing his resources.
Client App
An application making API request to the resource server to access user's resources.
Authorization Server
The server responsible for authentication the user and granting client application privilege(token) to access resource server if approved by the user
I am assuming you already have a Facebook account , and if not let's just pretend you have one. All information that you put there , your profile information, your pictures, your post belong to you. You own your data. Facebook also lets you set privacy rules allowing you to decide who you want to share your information with. Hence, you are the resource owner and Facebook is your resource server.
Now, if I was developing a social application, say FriendSight, that provides users with unique insights about their friends, I would need access to user's data from Facebook. In doing so I face following challenges :
- How do I get user's data from Facebook without asking for their Facebook credentials?
- How can I expect users to trust my application with their information?
- How does Facebook know I am an application that should be trusted?
OAuth2 addresses each of the concerns mentioned above. If I implemented OAuth2 in my application , the flow of my application would be as follows :
Step 1: Register FriendSight with Facebook
First, I need to register my application with Facebook by filling up a form and providing some basic information, more importantly the URL where it needs to redirect users in the login process. Once I register successfully, Facebook will issue a cleint id and client secret for my application. This piece of information is required to identify client applications to the authorization servers.
Step 2 : Seek user's permission to access their Facebook account
Users are not required to hand over their Facebook credentials. Instead, they will be redirected to Facebook's website where they will see a familiar login window
In this example, Facebook is both the Authorization Server as well as the Resource Server. In real word though they can be different. OAuth does not describe how both of them should communicate with each other, leaving the choice of implementation to the developers.
Step 3: After successfully login in, the user is asked to authorize FriendSight
The user can choose what information he wants to allow. He can be sure that only that much information and no more will be provided by Facebook to Client App.
Step 4: User is redirected back to FriendSight
Behind the scenes, FriendSight has obtained an authorization token from Facebook. This token encapsulates all permissions user has granted which will let it communicate with Facebook API
If you are considering using one of these technology in your application your decision should be based on the use-case. The following table describes some of the usage scenarios :
| Usecase | OpenID | OAuth2.0 |
|---|---|---|
|
I want to provide federated login in my application. I only need access to basic profile information such as name, dob and email address |
Yes |
Yes. Although its meant for authorization, in the process user also gets authenticated. The role of Resource Server is diminished in this use-case. |
|
I want to provide federated login in my application but I don't want to spend too much time and effort trying to figure out the technology. Also, I don't expect to register my application with the Authorization Server. |
Yes | Not recommended. OAuth2 requires Client App to register themselves with the Authorization Server. However, some Authorization Server may choose to accept anonymous Client Apps request |
|
I want to access user's data hosted on a remote server. The user should be able to delegate proper access to my application. |
No | Yes |
Comparing OAuth and OpenID is like comparing Apples with Oranges. They both serve very different purpose. One is for authentication whereas the other is for authorization. One is no more or less secure than the other. Which technology should you use is a question best answered by keeping in mind the usage scenario, complexity of the system and most importantly the technology supported by the Identity Providers or Authorization Servers.