I am writing an OAuth 2.0 client application and I am trying to use ImplicitAccessTokenProvider. But the problem is that this class allows for access token request by sending POST request to /oauth/token Authorization Server's endpoint.
For my Authorization Server to support this different Implicit flow implementation, I should change the Authorization Server to support Implicit Grant type to accept access token requests through /oauth/token. But it violates RFC 6749 because an access token must be implicitly retrieved in response of Resource Owner's authorization.
Does anybody have written any Client application which relies on ImplicitAccessTokenProvider to share the experience?
Related
I'm learning about the OAuth /introspect endpoint as a means to validate an Access Token. I'm using Okta, which I think is relevant to the question.
I've read online that the /introspect endpoint is intended to be called by an OAuth Resource Server (for example, an OAuth Client would call a Resource Server, providing an Access Token, and the Resource Server would call the /introspect endpoint to make sure the token is valid).
However, the /introspect endpoint (at least with Okta) requires you to provide the OAuth Client credentials (either as a basic auth header, or in the case where there is no client secret, just a client_id request param).
So, how can the Resource Server call the /introspect endpoint when it doesn't have the OAuth Client ID and/or secret? This is making me wonder if the /introspect endpoint is meant to be called by the OAuth Client instead, which to me, doesn't seem as useful.
Please refer to this article. Resource server needs to be a registered client application at Okta and client credentials in /introspect refer to this client's.
Based on my understanding the introspection endpoint is meant to be called by an API resource.
This endpoint is used by the API resource in order to validate the bearer token provided with an incoming HTTP request issued by a client application.
Most of the times this happens when the provided bearer token is a reference token, so the API resource server needs to known whether the provided reference token is associated with a valid access token. This information must be asked to the secure token server via a call to the introspection endpoint.
You can find more information here in the identity server docs. Identity server is a .NET implementation of the openid connect protocol, which is based itsel on oauth2.
This is a documentation that shows you how to call the introspection endpoint programmatically. This documentation is specific for a .NET library called identity model, but this is not relavant for your question, because the library simply implements the protocol.
As you can see in the example of the linked documentation, the client id that you need to specify when you call the introspection endpoint is simply the name of the API resource. The client secret is the API resource secret that you have defined for your API resource.
So, the source of your confusion is simply a terminology overload. In the context of the call to the introspection endpoint both of the following equations hold true:
client id == API resource name
client secret == API resource secret
This docs confirm both of my assumptions.
If it helps here are a few resources of mine, to add to Enrico's answer:
API Setup - see step 6 - you have to register an OAuth Client for the API
API OAuth Messages - see steps 16, 17 and 19 for the three types of response your API needs to deal with
API Code - for an example implementation in NodeJS
According to RFC6749 Chapter 4.1.1: https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1
In the specification of Authorization Request for Authorization Code grant,
Only client_id is required for Authentication. Since client type could be public, then that means anyone can get the Authorization Code, and then use it in Access Token Request - https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3. Here you only need to supply client_id (Which is public), Authorization Code (Which can obtain with NO authentication), redirect_uri and grant_type (Not for authentication/authorization purpose), and then you will be able to obtain an access token!
My question is, why there is NO any mandatory authorization/authentication procedure for this type of grant, then what is the purpose of having this type of grant? Same thing in Implicit grant.
The client authentication is not mandatory only for the clients that are registered as public client like Mobile Native Application. The Mobile Application can not hold client secret securely, hence it is not mandatory in authorization code grant and implicit grant. The client application like web application which can hold client secret securely in the server, such clients should be registered as confidential client. The clients that are registered as confidential client should present both client id and secret for client authentication.
OAuth2 server issues an authorization code after user authentication and after user approving consent with delegating rights to the client (identified by client_id). The auth code is then sent as a parameter to a client's registered redirect URI. So I don't know what you mean by "anyone can get the Authorization Code".
Public clients should be used with PKCE OAuth2 extension. Which serves as a one-time password. So even if an auth code get stolen, it cannot be exchanged for tokens without knowing the code_verifier parameter of the token endpoint.
If an attacker creates a malicious application using someone else's client_id (pretending to be the client), the auth code will still be sent to the client's redirect URL. If the attacker gets hold of this URL handler, then it's probably a problem beyond the scope of the OAuth2 protocol.
In OAuth2.0 Authorization Code Grant as stated in RFC 6749, the token request requires client secret according to sec4.1.3; however, the authorization request is not according to sec4.1.1.
Does anyone know why? It seems using client secret for both authorization and token request makes the process more secure.
They are different because they are two different types of requests. 4.1.1
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Is used to display the actual consent screen to the user.
Once the user has accepted then the code is exchanged for an access token
>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
No secret is needed because you are currently in the Authorization Code section of the document.
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
Authorization Code is sometimes refereed to as the Implicit flow, as the required access token is sent back to the client application without the need for an authorization request token. This makes the whole flow pretty easy, but also less secure. As the client application, which is typically JavaScript running within a Browser is less trusted, no refresh tokens for long-lived access are returned. Returning an access token to JavaScript clients also means that your browser-based application needs to take special care – think of XSS (Cross-Site Scripting) Attacks that could leak the access token to other systems.
Basically a user implicitly trusts their pc so there is really no need for the client secret validation step. Client secret is only needed for server sided applications where the user does not have access to the server so the server must validate itself.
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.
Does oauth2RestTemplate or access token providers support validate token request?
Here is the flow:
Mobile/Web-App authenticated from third party Authentication server
and obtains Access-Token.
User tries to access a secured resources, and passed the Access-Token in the request, as expected by the protocol.
Is it possible to check this token against third-party server?
I found a bit similar here in the form of a refresh token.
Is validation request the part of the OAuth2 standard?
Thanks
No, OAuth2 doesn't enforce a specific token format or API for validating tokens. This is something that has to be decided independently between the resource server and the authorization server.
For example, the UAA project, which uses Spring Security OAuth2, uses signed JWT tokens, so the resource server can validate the contents without having to ask the authorization server directly. It also provides a /check_token endpoint, which will decode the token and verify that it has not expired.