I don't quite figure out why oauth2 is for autheorization and OpenID Connect is for authentication purposes.
From OAuth2 RFC
authorization server
The server issuing access tokens to the client after successfully
authenticating the resource owner and obtaining authorization.
By other hand, according Authorization Code Flow RFC Agent or relying party is redirected to a some kind of authentication page in order to be able to authentication user, doesn't it?
Moreover, I've always read that OpenID Connect in built on Oauth2 in order to provide authentication mechanism to Oauth2. Is it right?
OAuth2.0 is an authorization protocol. OpenID Connect incorporates id tokens to add authentication on top of it
authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
Here the authentication is done for the authorization server, not for the relying party. Authorization needs to identify the end user and for that only the authentication used.
Once the authorization server authenticates the end user, it sends back access token which can be used to communicate with a protected endpoint. And the access token authorizes the relying party to use the protected service.
Access tokens never say anything about the end user. They are opaque to the RP and can only be consumed by the authorization server. But id token is a JWT with end user details. That's why I said OpenID Connect provides authentication.
How to choose between OAuth2.0 and OpenID Connect ?
There are many facts you need to consider. Which include the question of "does identity provider support protocols?". But, it all boils down to the fact of how you consume tokens.
If your client application simply allows the end user to consume protected endpoints and does not bother about their identity details, you should use OAuth2.0.
But if your client application is concerned about identifying end user and authenticating them(think about client application's other functionalities such as a database call or even a welcome message which require those) then you should use OpenID Connect.
Related
I am new to OAuth and OpenId, and after reading multiple pages and information I still do not feel confident at all.
My goal would be to create an iOS Application that communicates with my BE. I need the iOS app to authenticate the user to access their resources.
Reading about OAuth, the solution seems to be straight forward. Just use the Authorization Code Flow with PKCE to make the App have an Access Token. This way I am authorizing my iOS app to access user's data. When the iOS app calls https://example.org/user with the access token, the resource service (my BE server) can get the access token and call the introspection API to know to which user the access token is bound to, and return the correct user data. Since authorization needs authentication to be made in the first place, having the access token would mean that the user is (or at least was) authenticated.
First thing that confuses me: According to the OAuth specs, OAuth is not an authentication protocol, but still the protocol authenticates the user using the user's credentials. Why is OAuth asking the user for credentials, instead of relying on another protocol/flow for user authentication? Such protocol would just acknowledge to OAuth that the authentication was successful.
This first issue made me start reading about Open ID Connect specification and the ID Token. This token would be received by the iOS app. What is the iOS App supposed to do with it? I can already get the user information calling the /user endpoint. How would this ID Token be an advantage?
tldr
Access token (OAuth 2.0) - authorize against OAuth protected
endpoints.
ID Token (OIDC) - authentiation by client application.
Authorization server authentication - It's there to detect
authenticity of end user involved in both protocols (pseudo
authentication from client application perspective)
OAuth is not an authentication protocol, but still the protocol contain a step to authenticate the user using the user's credentials
Correct, OAuth is not an authentication protocol. It is for authorization, which means identifying there are correct access grants to access a protected resource (protected resource ? ex:- An API, A photo stored in a backend).
So why you see end user login dialog ? Well that is the job of authorization server. It authenticate end user to be known by it and then issue the access token to client (client == in simple terms the application which end user uses). So yes there is an authenitcation happening, but this is not applicable to your client application or protected endpoint. One can define this as an pseudo authentication.
OpenID Connect - For authentication of client application
In the original RFC (RFC-6749), OAuth 2.0 was defined as a framework. OpenID Connect was an extension that built on this framework. What it provide ? Well as you found out, it introduce the ID Token. And ID token is issued by authorization server to be consumed by your client application. It contains end user identity information in JWT format. By validating integrity of this token, your client application can authenticate the end user. And access token ? That's there to used against protected endpoint. It doesn't say anything about end user to client.
I've began to take interest in the OAuth 2.0 specification and am not sure if what I've understood so far is correct.
OAuth is an authorization protocol while OpenID Connect is an authentication protocol which extends OAuth.
The first deals with authorizing access to a 3rd party resource, by a client application. Example you are building some app and would like to use some other application (which is not yours to own) features (resources).
On the other hand OpenID connect, deals with authorization, authorizing some human entity by verifying his/hers identity to, for example, access a specific resource that only him/her alone has access to. Example you're a banking application and allow users to access their account but first they need to confirm their identity with an Authorization Provider.
So is it safe to say that Authorization is destined to application interaction while Authentication for human interaction ?
Your understanding on OAuth and OpenID Connect is correct. When OAuth was introduced, it define a way to obtain access tokens, which the holding party can used against an endpoint protected by OAuth access tokens. This allowed identity details to be stored in a central location (authorization server aka identity servcer) and that central location to maintain token obtaining process (which include human authentication too).
While access token are used to grant access (authorize), OpenID Connect introduced ID token that get transmitted along with access token. The ID token is there to be consumed by the client application, which is used to authenticate the end user.
Token obtaining require authentication at authorization server. Depending on the token obtaining flow (aka OAuth grant), this authentication will involve the human user. It is also possible to follow a flow which does not involve a human user. Such flow only produce an access token. And OpenID Connect can only be used when human user is involved.
Q : So is it safe to say that Authorization is destined to application interaction while Authentication for human interaction ?
If your application (client) involves and end user, then that user can involved in token obtaining flow. And you can obtain access token as well as ID Token. Then you use ID token for end user authentication. And access token is used to connect with another endpoint.
If your application does not involved an end user (ex:- A service), then you will use OAuth to obtain access token, which used against another endpoint.
Assume aim is to authorize access to Resource Server (RS) resource.com/resource via access token but using OpenId Connect for authentication instead of relying on custom authentication integrations of Authorization Server available in OAuth2.
I am not clear how they interoperate, how does the id token feed into subsequent OAuth2 flows in particular.
1.OpenId Connect is implemented as an OAuth2 "authorize access to user profile/identity", but what flow does it use for it?. At this point, The requester (user agent or client app) gets id token and access token to userInfo.
2.But now, identity obtained, an authorization/access token to end service (Resource Server RS) is needed.
What is the next step until the end goal of access token to Resource Server?
Here we have another OAuth2 flow, so that based on identity of user and client the end access token is obtained. I do not have the details of this. I saw detailed presentations of OpenId connect up to the point of having the id token and access token to userInfo and detailed presentation of OAuth2 flows all 4 of them, but never saw an end to end concatenation of these protocols, is there such an integration?
Does the requester send the id token to authorization server together with the request for code or access token directly (depending on the flow)? I never saw an end to end flow, can you indicate a video or text description of it?
Normally, client applications don't send ID tokens to authorization servers. (In the specification, there is a request parameter id_token_hint. But, it should be ignored here to avoid confusion.)
Normally, resource servers require only access tokens. Client applications don't have to send ID tokens to resource servers.
Reading "Diagrams of All The OpenID Connect Flows" may help you.
I've read a number of different write-ups on this now, but I'm still unclear as to the primary value that OpenID Connect provides on top of OAuth 2.0.
My understanding:
When receiving an access token via the OAuth 2.0 flow, the client does come to know that the user was authenticated by the authorization server. It seems like OpenID Connect is just adding an ID token with user information - but that information could be part of the access token or available through a protected resource (like a separate userDetails resource). That doesn't seem to justify the creation of OpenID Connect, so I'm sure that I'm missing something...
Thanks for your help!
Adding more details that are too long for a comment. Thanks much for your help so far.
I think I'm getting closer, thanks to your responses. So I reviewed this article: http://oauth.net/articles/authentication/. It says that "OAuth says absolutely nothing about the user". However, you are trusting that same service to authenticate the End-User before issuing an Access Token. In the "common pitfalls section", the article discusses why you can't use access token for authentication. I have the following issues with that in my understanding:
Access token as proof of authentication
The access token was proof of authentication at some prior point. If the Client does want to authenticate the user at some point after getting an access token, why not just repeat the existing Oauth flow with the current end-user trying to access the client?
Access of a protected resource as proof
Same as above - if the client requires authentication at any point, repeat the Oauth flow.
Injection of access tokens
Not clear how OpenID helps this
Lack of audience restriction
Why is it harder to hand a naive client a valid ID token along with the access token? Is this relevant at all to the server-side flow? And again, can repeat the OAuth flow if needed.
Injection of invalid user information
This seems to require a signature, not a separate token. If the OAuth flow takes place over HTTPS, is it adding any security for the identity provider to sign user details twice?
Different protocols for every potential identity provider
This seems fair, but it still seems strange if the only purpose would be standardization of the token used for user information.
An OAuth access token is opaque to the Client and could have been provided by anyone, which means that it is not necessarily handed to the Client by a logged in user. An attacker could provide an access token to the Client that it got from a different user in its own (not necessarily malicious) service. The ID token from OpenID Connect make sure that the user was logged in recently at the OP and provides information about that user that can be verified by the Client. Moreover the ID token is targeted specifically to your Client.
The differences are described pretty well in http://oauth.net/articles/authentication/
An ID token can be signed by the authentication server. A client application can verify the signature to confirm that the end-user has been authenticated by the very authentication server. Access token + protected resource call do not provide such a mechanism.
In addition, OpenID Connect has introduced other mechanisms related to authentication such as:
Authentication Context Class Reference
Maximum Authentication Age
sub claim in claims request parameter
to satisfy higher-level security requirements by governments.
Read OpenID Connect Core 1.0 and other related specifications. Also, you may find "Authorization interaction" helpful as a summary about what OpenID Connect has added to control end-user authentication.
OAuth 2.0 is about granting a third party limited access to a resource. The RFC starts with
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service...
OpenID Connect is about establishing an end-user's identity. The OpenID Connect Core spec starts with
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User
based on the authentication performed by an Authorization Server...
In OAuth 2.0, when a resource server receives a request containing an access token, the resource server knows that the resource owner has granted a third party access to a resource. The access token represents this approval but it does not identify the third party who is presenting it.
If a company thinks someone like Salesforce or Google is better equiped than they are to manage user accounts, passwords, digital certificates, etc., the company could use OpenID Connect to essentially "outsource" that responsibility to an OpenID Connect Provider. When the company receives an id token in the context of an OpenID Connect flow, it knows that the provider has authenticated the end-user and established the user's identity.
OpenID Connect has repurposed the OAuth 2.0 flows so that the identity of an end-user can be established.
OAuth terminology has been bothering me a long time now. Is OAuth Authorization as some would suggest or is it Authentication?
Correct me if I'm wrong but I have always read Authorization as being the act of allowing someone access to a resource yet OAuth doesn't seem to have any implementation that actually allows access to users to a given resource. All OAuth implementations talk about is providing a user a token (signed and sometimes encrypted). This token is then passed with every call to a back-end service endpoint where it is checked for validity, again not an OAuth concern.
Is OAuth Authentication (every article says it isn't) which I take it requires a user to provide credentials which in turn proves a user should/shouldn't have access?
So it seems that OAuth is not Authorization NOR Authentication since these have to be performed by other processes. So what the heck is it? Is it a process for communicating a token? Is it fluff word that really has no specific meaning?
It's hard to ask a question about this subject without sounding enigmatic and superstitious (ghosts and goblins) so I expect that answering this question won't be a simple thing either. Enter at your own risk.
OAuth is a specification for authorization
OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:
The authorization endpoint is used to interact with the resource owner
and obtain an authorization grant. The authorization server MUST first
verify the identity of the resource owner. The way in which the
authorization server authenticates the resource owner (e.g., username
and password login, session cookies) is beyond the scope of this
specification.
OAuth authentication?
Authentication deals information about "who one is". Authorization deals information about "who grants what permissions to whom". Authorization flow contains authentication as its first step. It is the reason people are often confused.
There are many libraries and services that use OAuth 2.0 for authentication. It is often called "social login" and It makes people more confused. If you see "OAuth authentication" (not "OAuth authorization"), it is a solution using OAuth for authentication.
OpenID Connect
OpenID 1.0 and OpenID 2.0 are old specifications for authentication. Those who made the specifications expected people to use OpenID for authentication. However, some people began to use OAuth 2.0 for authentication (not for authorization) and OAuth authentication has prevailed rapidly.
From a viewpoint of OpenID guys, authentication based on OAuth was not secure enough, but they had to admit that people preferred OAuth authentication. As a result, OpenID guys decided to define a new specification, OpenID Connect, on top of OAuth 2.0.
Yes, this has made people much more confused.
One-sentence definitions of OAuth 2.0 and OpenID Connect
OAuth 2.0 is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.
OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user's identity information which is managed by a service.
(Sorry, these definitions are excerpts from the overview page of my company)
Definitions from a viewpoint of implementors
Authentication is a process to determine the subject (= unique identifier) of an end-user. There are many ways to determine the subject. ID & password, fingerprints, iris recognition, etc.
Authorization is a process to associate the subject with the requested permissions and the client application that requested the permissions. An access token represents the association.
See Also
Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings
Diagrams And Movies Of All The OAuth 2.0 Flows
Diagrams of All The OpenID Connect Flows
The Simplest Guide To OAuth 2.0
OAuth is an authorization protocol. It is not designed for authentication. Yes, there is a step in the OAuth process where the identity server authenticates a resource owner. The way it happens does not belong to the OAuth protocol. That is why OAuth does not concern itself about authentication.
OAuth performs authorization by giving an access token to a third party (service provider) and that party will be able to authorize access to the resource by presenting the token.
Let's say there is a requirement that a service provider wants to access resources (protected by an identity server) on behalf of the resource owner. So the resource owner will first authenticate and then will grant permission for the service provider to access specific resource. Then the identity server will issue an access token for service provider. Later the service provider can access the resource with that token.
Here, OAuth does not care about who is carrying the access token or trying to access the resources. It validates the access token, and lets the third party access the resources.