I am writing an API that uses the OAuth 2.0 password flow to authenticate users. When a request for an access token is denied, there does not seem to be any way for a client to tell whether the password was incorrect, or expired. From the spec, an error code of invalid_grant should be returned in both cases:
invalid_grant: The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
Is it acceptable to use the error_description on the response to state that the password has expired so that the client can take the necessary action, and if not, what is the standard approach for handling password expiry with OAuth?
"Leaking" that the reason for such a failure such as "password was incorrect, or expired" is NOT a best practice for authentication.
I would suggest that the "server" log the reason for the failure and NOT return the information to the requestor.
Related
when client requests resource with jwt-token, first resource need to verify token. In simple scenario , resource server verifies itself. But there are cases when oauth server is called to verify the token.
So my question is, why oauth server could be called to verify the token?
It all depend's on how you are using validating token.
Methods used for validating token
Introspection
This is a method to get actual token information via special endpoint
directly from the Authorization Server. Token information usually
includes token type, status (active or not), user, client identifier,
available OAuth2 scopes, and expiration time.The method requires
direct interaction with Authorization Server for every token
validation. It has high safety but low performance.
Token validation by signature (JWT tokens only).
This is a method when the token is validated according to its
cryptographic signature and all required token information is received
from token itself. It means that token validity is verified without
interaction with an Authorization server, and if the token was revoked
before its expiration, we’ll never know about it. So, this method is
fast but less secure than introspection.
You can have more details on token validation on https://dzone.com/articles/oauth2-tips-token-validation
If you request a token from the server (with the same credentials and within the lifespan of an old token) should it either:
return a fresh token every time
return the same token with a shorter lifespan
something else / depends on
Is it depending on whether you use a refresh token?
Can you please reference the OAuth 2 RFC in your answer ?
The OAuth 2.0 Authorization Framework is a framework that allow a Resource Owner to CONSENT to allow DELEGATION of their permissions to access a Resource Server to another party (OAuth Client).
The Authorization Request is performed by the OAuth Client and is fulfilled by the Authorization Server only after obtaining CONSENT from the Resource Owner by the Authorization Response (which includes a Access Token).
The Access Token is a Bearer Token with a limited lifetime.
The refresh Token, if used, by the client to requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
The "same" Access Token is never returned or reused by the Authorization Server.
Reading and following the Security Considerations with any Authentication or Authorization Protocols is a must. Most breaches are caused by implementation errors rather than protocol errors.
You should Tell us what you have tried and show logs or results and Read:
https://stackoverflow.com/help/how-to-ask
I use [JWT for Client Authentication][1] in [Keycloak][2]:
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=vAZEIHjQTHuGgaSvyW9hO0RpusLzkvTOww3trZBxZpo&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
client-assertion-type%3Ajwt-bearer&
client_assertion=eyJhbGciOiJSUzI1NiJ9.
eyJpc3Mi[...omitted for brevity...].
cC4hiUPo[...omitted for brevity...]
I get :
assess_token
refresh_token
token_type
expires_in
When I try to refresh token I send refresh_token itself, grant type refresh_token and get:
"error": "unauthorized_client",
"error_description": "INVALID_CREDENTIALS: Invalid client credentials"
}```
when I specify `client_id` I get:
```{
"error": "invalid_client",
"error_description": "Parameter client_assertion_type is missing"
}```
If I specify `client_assertion_type` I get error that `client_assertion` itself is missing, so I literally have to provide parameters I provided when retrieved access token.
How that refreshing process actually should work?
[1]: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bearer-12#section-2.2
[2]: https://www.keycloak.org
This could very well be a limitation or policy defined by Keycloak. RFC7523 (JWT for Client Authentication) does allow to enable client credentials when JWT authentication is present. This is highlighted from 3.1. Authorization Grant Processing
JWT authorization grants may be used with or without client
authentication or identification. Whether or not client
authentication is needed in conjunction with a JWT authorization
grant, as well as the supported types of client authentication, are
policy decisions at the discretion of the authorization server.
However, if client credentials are present in the request, the
authorization server MUST validate them.
So even if Keycloak support JWT client authentication, it may still require client credentials to be present in the refresh token request. But also, it could be a limitation from their end.
Additionally, token refresh is defined through RFC6749 - The OAuth 2.0 Authorization Framework. According to it's section 6, refresh token request must contain client credentials when client is a confidential client (simply a client which was created with id and a password). If what you seen is not a limitation, then guess Keycloak adhere to RFC6749 and require you to send client credentials in token refresh request.
I have implemented Identity Server 4 with a password grant type flow. I would like to know if it is possible to implement a refresh token so the client does not have to resend the username and password when the auth token expires. If so, can I please have some documentation.
Thanks
Greg
According to the docs:
Refresh tokens are supported for the following flows: authorization code, hybrid and resource owner password credential flow. The clients needs to be explicitly authorized to request refresh tokens by setting AllowOfflineAccess to true
So in theory you should be able to implement it, by setting the required parameters.
Just as an FYI, there is something else. Again from the docs:
The resource owner password grant type allows to request tokens on behalf of a user by sending the user’s name and password to the token endpoint. This is so called “non-interactive” authentication and is generally not recommended.
So if you have the chance to use another grant type - I would advise you so. If not, the answer to your question is - yes, you can use refresh tokens with the Password grant type
I just have a question re client_credentials grant type in OAuth 2.0. When a client requests for an access token 2 times, will the access token requested on the first time be invalid?
Thanks!
The first obtained access token will be valid until it expires.
A token contains an authentication ticket including the indentity and an expiration time. When the token is decrypted, the server obtains the ticket and checks that the ticket is not expired. It uses the claims included in the ticket for authorization tasks.