OAuth2 and Authentication
1.What is the difference between authentication and authorization?
Authentication is the process, by which a server checks if a user is indeed the user that it claims to be. This is usually done, when the user gives the username and a password, while the server checks these credentials (username, password) with those stored in its database, when the first user created its account. Authorization is when one entity gives permission to another entity to perform an action. In this case, for instance, it's when a site wants to access data of a user, which are stored and owned in a different website.
2.What is OAuth2 meant to do?
Officially, OAuth2 empowers a user to allow a client website C to access his/her data from a resource server website RS after authentication via an authentication server website AS. This seems quite complex, so to simplify, a common example is when a user signs in a website using his/her facebook account. In that case, the client website and the resource server website are the same (C=RS=the visited website) and the authentication server is facebook (AS=facebook). Note that this was created, so that the C,RS do not learn the password of the user, while being able to authenticate him/her.
3.Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?
The specificity with the implicit flow is the fact that the access token is given to the user-agent to forward to the application. So, it is solely based on the redirect URI. Thus, this flow does not authenticate the identity of the application, since there is no client secret confidentiality (access token exposed to user and applications running in mobile)
4.What is the difference between OAuth2 implicit flow and Oauth2 authentication code flow and when to use which?
As described before, in implicit flow the access token is forwarded to the application by the user-agent. On the other hand, in authorization code flow, the client web server gets first an authorization code (after the Resource Owner / user gave access), then makes a call to the API passing (clientID,secretID) with the authorization code to get the access token. This is done, so that in case of HTTP connections (no SSL encryption), the access token is not accessible to man-in-the-middle (routers,proxies etc.). So, the first one is suitable for mobile applications, while the latter one is suitable for server-side applications.
5.Does OAuth2 authentication code flow work for authentication?
Yes, the authorization code flow also authenticates the user through the authentication server.
6.Should you use OpenID instead of OAuth2 for authentication?
Yes.
OpenID is used for authentication. An example is when we want users to be able to sign in in multiple websites with a single set of credentials (signle-sign on).
OAuth is used for authorization, as desribed before. Note that OAuth can be slightly adjusted (as in the example before, where C=RS) in order to perform (pseudo-)authentication, via authorization. But, if we only want authentication, we can use OpenID.
7.Why is google saying that their "OAuth2" framework can be used for both authentication and authorization.
I guess the real reasons behind this design decision can only be given by the corresponding Google engineers, but I could assume that instead of using both OpenID and OAuth, they selected to use a single protocol for both usages, in order to simplify things. However, be aware of the fact that authentication via OAuth is being done by authenticating someone, through the data he/she possesses. A dull example would be that when I am trying to enter my job's building, I am not asked about my credentials, because my employee card is obviously in my neck. This is how authentication is being made via OAuth, quite simplified. So, you can see that this can make several assumptions that do not always hold under every scenario. And this is the reason that it is generally recommended to use OAuth only for authorization and use OpenID, should you also need to implement authentication.
A nice link describing the various flows of OAuth for reference
@RaptisDimos gave a good answer but I think I will expend on point #3.
- Why is OAuth2 implicit flow insecure for authentication while still secure for authorization?
The problem with the implicit flow when you try to use it for authentication is that the client directly receive an access token and that access token is not bound to any specific client. What this means is that the client doesn't know if this token was meant for him or another application.
This token is then used to access the owner data. When you want to "authenticate" the owner, you usually pull his email from his data and you authenticate him in your application (client). But, you don't know who passed that access token to your client. Was it the real owner or an attacker hosting another service?
Example of an Attack
- Client_Good : A good client using google API to authenticate it's user using the implicit flow
- Client_Bad : A malicious client using google API and attacking Client_Good
Client_Bad can be any service. For example, a web application that let you upload picture in your google drive. In order to achieve that task, Client_Bad need an access token from Google. So it will ask you to provide him with one. Then, you will be able to use its service to upload your picture.
What you didn't know is that the access token you just gave to Client_Bad in order to upload pictures is also a valid access token that could be used with Client_Good to authenticate yourself. Now, the owner of Client_Bad, can impersonate you in Client_Good. If Client_Good was a critical service, you could be in serious problem.
Why is it secure for authorization then?
It's secure because if you give the authorization to Client_Bad to upload picture on your behalf, it doesn't matter if he's doing it directly or is passing by another service to do it.
For example, there could be a third client, Client_Picture, that also just upload picture to your google drive. When you ask Client_Bad to upload your stuff, Client_Bad could delegate that task to Client_Picture and you wouldn't care as it achieved the same result.
Well, there is the fact that now a ton of 3rd party could have access to your data but again, you agreed that Client_Bad could do whatever it wishes with this access token when you gave it. It's like passing the key of your cars to your neighbor. You gave someone else the right to use that car, he might then loan it to another neighbor for a while then give it back to you. The thing is you don't know and you "agreed" to that when you gave the control.
Note: Sometimes I wonder if no one understand the explanation or if I said something wrong... Anyway, it's explained in the section 10.16 of OAuth2 specification in other words if that helps.