Please refer to this video, specifically from 20.00 to 25.00.
https://azure.microsoft.com/en-us/resources/videos/new-authentication-model-for-web-mobile-and-cloud-applications/
The work flow he describes is this:
Client app connects to authorization end point through the browser. User enters credentials, and authserization server authenticates the user and sends the auth code using a re-direct. Client app intercepts the browser activity and extracts the auth code. A new request is made to token end point together with this auth code, client id and few other information. In return, app gets access and refresh token.
What stops some one from stealing the auth token in the first step (say through browser history), and then contacting the token end point to get access and refresh tokens?
First off authorization code is only good for about 3 minutes normally. Second authorization code can only be used once. Third redirect uri must be a valid one that was registered for this client on the oauth server
The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
#section-4.1
Oauth flow
Lets do this with some correct terminology.
Client = your application
authority= identity or oauth2 server (authority)
resource owner = user whos data you wish to access.
Resource owner loads client, client notices that resource owner is not authorized. Resource owner contacts authority identifying itself using a client id and possibly a client secret and sending a redirect uri, and requests scopes. (some of the things sent depend upon the setup of the auth server)
Authority notices this resource owner is not logged in prompts them to log in. Resource owner logs in and checks what scopes the client originally requested. Prompts resource owner to grant client access to said scopes.
Resource owner consents to access. Authority returns to the client an Authorization code.
Client says nice i have an authorization code and returns to the authority the authorization code and its client id and secret. This way the Authority knows that this is in fact the client that the resource owner authorized.
Authority then returns an access token back to the client that it can use for the next hour.
Access tokens are not then re-validated. So if someone stole this access token they would be able to use it until it expires.
Related
In OAuth2 protocol, Client (RP in terms of OIDC) application obtains an access token, which enables it to use different services (Resource server role) on behalf of a Resource Owner.
On the other hand, in the OpenID Connect protocol, Client obtains 2 tokens (access and id token). Now this Client can use the access token to fetch user claims from the UserInfo endpoint.
Does OP (Authorization server) play role of a Resource Server here (in terms of OAuth2), and Client fetches user data on behalf of a user?
How is ID token used by the Client? Does Client pass this ID token to the Resource Owner's user agent (Browser) and then, user agent stores this token to enable SSO (cookie)?
Does Client (e.g. different one than the one that obtained the ID token) has to verify the token every time user accesses it (call OP to verify it), or Client does this only first time it gets accessed by this token and then creates security context which enables it to eliminate this request for verification at OP every time? In this case, how could this security context be implemented?
What is the access token used for, except for fetching user claims and why is it sent along with ID token, when Client could use ID token to access UserInfo endoint?
First of all you must understand the purpose of tokens. Access token is a token that is good enough to access a protected resource on behalf of the end user. It is defined by OAuth 2.0 authorization framework. Now having an access token does not authenticate the end user. it simply authorize the client application to access a resource. OpenID Connect introduce the ID Token. Now this token is to be consumed by your client application. Protocol define how this to be done and if valid, your client application can authenticate the end user.
Q: Does OP (Authorization server) play role of a Resource Server here (in terms of OAuth2), and Client fetches user data on behalf of a user?
Partially correct. According to the protocol document, userinfo endpoint acts as OAuth 2.0 protected resource.
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication.
Q: How is ID token used by the Client? Does Client pass this ID token to the Resource Owner's user agent (Browser) and then, user agent stores this token to enable SSO (cookie)?
As mentioned previously client must validate the id token and based on that it can authenticate the end user. ID token is not connected with SSO.
Q:Does Client (e.g. different one than the one that obtained the ID token) has to verify the token every time user accesses it (call OP to verify it), or Client does this only first time it gets accessed by this token and then creates security context which enables it to eliminate this request for verification at OP every time? In this case, how could this security context be implemented?
If you are using ID token to be consumed from a protected endpoint, then token receiving party should validate it before accepting it. One may choose to create a session after a proper token validation (session must not extend the life time of the token).
Q: What is the access token used for, except for fetching user claims and why is it sent along with access token, when Client could use ID token to access UserInfo endoint?
Access token is the token your should use to access OAuth 2.0 protected resources. Once the endpoint received it, endpoint can validate the access token against token introspection endpoint exposed by the authorization server (Protocol definition of introspection). And with Openid Connect, defining of userinfo endpoint let any party with valid id token to consume it.
I don't see how you can be confused about that if you've read the RFCs.
You want to think of identity as a "resource" service? fine, but the authentication for this service is different than for RPs, so what's your point?
The Client exists in the User Agent (we're talking about SPAs, right?). If the ID token is in the Client, then it's in the UA (the reverse is not true). If you're thinking of server-side clients, then there is no need to forward the ID token to the UA, unless you want the UA to pass it on to another Client (e.g. for SSO). There are SSO schemes that use the ID token for convenience, but that's not the stated purpose of the ID token.
The whole point of JWS is that you don't need to call the OP to verify a token. You just verify the signature. That may be done by any Client, whether they're the original recipient of a token, or they get it later. Furthermore, the ID token is not meant to authenticate the user. Using it for SSO requires some other form of security, such as storing a related secret in an HTTP-only cookie that will not be seen by the Client. Anyway, even if you use the ID token for SSO, then the ID token is sent only in the login request. After that, the Client will get its own access token for authentication and will not use the ID token again.
The access token is typically short-lived (which means the Client has to contact the OP regularly, which allows the OP a chance to revoke access). The access token is sent with every authenticated request, so it should be small (i.e. not contain user information that is not useful for authentication).
I have a question about PKCE (RFC 7636). OAuth clients that use the authorization code grant have two components: (1) the portion on the resource owner's device that initiates the authorization request and (2) a redirection endpoint on a server that can accept and send HTTPS messages.
The PKCE extension to OAuth has the clients do this:
Generate a cryptographic random string called a code_verifier.
Create a SHA-256 digest of the code_verifier and Base64-encode it.
Send that along with the authorization request.
When the client gets the authorization code and sends it to the token
endpoint for an access token, include the original code_verifier value.
Step 2 happens on the resource owner's device. Once the resource owner has approved the request, his/her browser is redirected to the client's redirection endpoint. Step 3 happens at the redirection endpoint.
So the question is, how does the redirection endpoint know the code_verifier value? It was generated on the resource owner's device.
So the question is, how does the redirection endpoint know the
code_verifier value? It was generated on the resource owner's device.
Because the redirection endpoint effectively routes to an endpoint on the same device which called the authorise endpoint.
It may be registered as a loopback redirection, a app-claimed redirection or a custom URL scheme but the device will route the redirect to the appropriate app or the app will be listening on the appropriate port for loopbacks.
OAuth clients that use the authorization code grant have two
components: (1) the portion on the resource owner's device that
initiates the authorization request and (2) a redirection endpoint on
a server that can accept and send HTTPS messages.
Confidential clients have a redirection endpoint on a server that can accept and send HTTPS messages.
Public clients do not - and native clients using PKCE are still public clients.
To build on the information provided, PKCE is designed to ensure that the redirect URI routes back to the requesting app, and not a malicious app via an Authorization Code Interception Attack. In this scenario, the legitimate app will know the verifier but the malicious app will not know the verifier.
PKCE Legitimate App Flow
A legitimate app flow looks like the following where the authorization token request is redirected back to the SystemBrowser and then back to the originating NativeApp.
Ref: http://openid.net/2015/05/26/enhancing-oauth-security-for-mobile-applications-with-pkse/
Authorization Code Interception Attack
A malicious app can be introduced to the OS. With, or without PKCE, the native app can receive the authorization code, but it will not know the verifier and thus cannot complete the token exchange.
Ref: https://docs.wso2.com/display/IS520/Mitigating+Authorization+Code+Interception+Attacks
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.
So, a basic OAuth2 flow using authorization grant type would normally go as follows, (assume OAuth Client=Quora, OAuth Server=Google, for eg. purposes):
User goes to Client, is redirected to Server sign in page for authentication.
User logins to Server, and Server returns an authorization_code to Client.
Client then makes a call with client_id, client_secret and authorization_code to Server to fetch the token.
Server validates and replies back with token.
Client can now access api/resources from Server with the token.
Now, if the user already logged in to say, Server first, then tries to access Client,
How will Client know that user is already logged in to Server, (as client cant access cookies from server domain)?
From where will the Client get the authorization code to fetch the access token?
Good question. Here's what happens:
Client is redirected to Server page for authorization.
Server (Google) has cookies set in the browser for THEIR domain only (from last time), and can see the user's information.
Server (Google) generates a NEW authorization code, and redirects BACK to the Client webapp with that code.
The Client app then makes an API call to Server with client_id, client_secret, and NEW authorization code token and gets a new access token.
Client app then creates a cookie (or uses local storage) to store this new Access Token and keep the user logged in.
I am currently trying to implement a web service (API) with OAuth2 authentication using Spring Security OAuth. As far as I understood, given a user, a client app and a server, the authentication process is as follows:
User requests resource from server via client
Client retrieves request token from server
Server responds with a temporary request token and a redirect URL
Client loads web page (redirect URL) and lets user enter credentials in order to authenticate the request token. The form inputs are sent to the server, input is unknown to client.
Server replies with an authorization code, which is handed to the client
Client uses authorization code to retrieve an access token (and, optionally, a refresh token if one was requested)
User hands access token to client
Client uses access token to retrieve requested resource
In Spring OAuth, there are three grant types to request an access token:
Authorization Code, which is the method I described above, refresh token, and user credentials. I don't know how retrieval by user credentials works, is it similar to retrieval via refresh token?
A couple of statements you are making above are incorrect. Probably it's a good idea if you have another look into the OAuth2 spec: https://www.rfc-editor.org/rfc/rfc6749
To concentrate on your question I just refer to the last paragraph of your question here after.
OAuth2 supports 4 grant types, namely 'Authorization Code', 'Implicit', 'Resource Owner Password Credentials' and 'Client Credentials'. The one you are refering to as 'user credentials' would be 'Resource Owner Password Credentials'. In this grant type you loose OAuth's benefit of not having to hand over resource owner (aka user) credentials to the client. However it still has the benefit of not having to store the password on the client and sending it for each resource request, since a token is used instead. The process flow is as following:
resource owner sends credentials to client
client sends credentials to authorization server
server returns access token (and optinally a
refresh token)
client uses access token in subsequent request to
ressource server
So yes, you could say that the flow of the Resource Owner Password Credentials grant is similiar to the flow when a client already has a valid refresh token (from which ever grant).