I'm doing authorization with Azure AD (using /oauth2/v2.0/authorize) with these scopes:
openid email profile https://graph.microsoft.com/user.read
In response, I get an id_token and an authorization code. I ignore this id_token and use the authorization code to get an access token (using /oauth2/v2.0/token)
When I get the access token, I again get an id_token along with it.
The Microsoft docs state:
When your app receives an ID token, it must validate the signature to prove the token's authenticity and validate a few claims in the token to prove its validity.
But since my app received the ID token based on its own HTTPS post to a Microsoft server, is it safe to use the ID token without validating it?
According to what you have described,
You are using OpenID Connect
You are using the hybrid flow (with response_type=code id_token)
If you are not expecting an id token from authorization request, you can use use other either Authorization code flow or Implicit flow
These flow types are selected from response_type parameter and not from claims.
For authorization code flow,
response_type=code
For Implicit flow,
response_type=id_token token or response_type=id_token
Note that, implicit flow does not produce an access token and is intended for JavaScript or similar clients which cannot protect a refresh token.
Once you get the id token from the token endpoint or from authorization endpoint(based on implicit flow), you can validate it just once.
Related
Currently I am using /token endpoint to obtain an access token, an ID token (by including the openid+offline_access scope), and a refresh token for the Authorization Code flow. The value for code is the authorization code that I receive in the response from the request to the /authorize endpoint.
Also to refresh access token as well as an ID token, I am sending a token request with a grant_type of refresh_token.
Below is the reference link, I am trying similar to implement in my custom OIDC application.
https://developer.okta.com/docs/guides/refresh-tokens/main/#renew-access-and-id-tokens-with-spas
Does it suppose to return both refresh_token and id_token OR both are optional if grant_type=refresh_token (also in token endpoint openid+offline_access scope added) in OpenID Connect concept?
Below is the link I am trying to understand.
https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokens
When you use the refresh token, the purpose is to get a new access token. Optionally, depending on the backend configuration, you might get a new refresh token as well (if you use a one-time refresh token setup).
You never get a new ID-token back, the ID token is usually a very short-lived token (like 5 minutes) and its main purpose is to describe how the user is authenticated and who it is. The main purpose of the ID token is to create the local session (typically a session cookie), after that the ID token has no real use.
I am using client credentials flow of OAuth 2.0 client credentials grant. I have given the necessary permission Calendars.ReadWrite in my Azure application, which is needed for the api endpoint 'https://graph.microsoft.com/v1.0/me/events'. I am able to get the token from Servicenow using the api '/{tenant}/oauth2/v2.0/token' and passing the scope as myappURI/.default. But while using the token for the posting an event using the api 'https://graph.microsoft.com/v1.0/me/events' I get 'Code:InvalidAuthenticationToken. Message:Access token validation failure. Invalid audience' error. Any help on this will be much appreciated.
You need to send https://graph.microsoft.com/.default for the scope.
4. Get an access token:
You specify the pre-configured permissions by passing
https://graph.microsoft.com/.default as the value for the scope
parameter in the token request. See the scope parameter description in
the token request below for details.
https://learn.microsoft.com/en-us/graph/auth-v2-service
In my case I was sending the ID Token instead of the Access Token.
ID tokens are meant to be read by the OAuth client.
Access tokens are meant to be read by the resource server.
ID tokens are JWTs. Access tokens can be JWTs but may also be a random string.
ID tokens should never be sent to an API. Access tokens should never be read by the client.
Source: https://oauth.net/id-tokens-vs-access-tokens/
I am using Forgerock as my identity provider and am looking for something in their rest api where i can provide an access token in the form of a Authorisation Bearer Token and get the corresponding JWT token to use as a Authorisation Bearer Token in a subsequent rest api call.
Can someone help me with what endpoint I can call in Forgerock to do this? I've had a look at the userinfo endpoint, that seems to return what is in the id_token in json format, but I want the actual id_token. A "token exchange".
thanks
There is no endpoint defined by specifications to obtain and ID token for an access token. Specificaitons define about token intrsopection endpoint (RFC7662) and user info endpoint (which you have already figured out).
Other than these, best option is to obtain ID Token from token response itself. For this you need to follow OpenID Connect request format, which include scope value openid. For this, you will require end use consent (most of the time) which allows authorization server to share their claims through id token.
Google Doc says that you can specify response_type for gapi?.auth.authorize
You can use it to get id_token
The Scenario
I've recently built an API, and have protected its resources using OAuth Bearer Access Tokens.
I've used the Client_Credentials Flow, as it will be accessed by clients as opposed to users.
Here's the thing, when a client has successfully provided the client_id and the client_secret they receive a response like the following :-
{
"access_token": "<Access Token>",
"token_type": "bearer",
"expires_in": 1199,
"refresh_token": "<Refresh Token>"
}
Refresh Tokens.
Not knowing much about refresh tokens, i immediately assumed that a client would be able to provide the OAuth Server the refresh_token to retrieve a fresh Access_Token.
This is 'kind of' correct.
In order to use the refresh_token the client still needs to pass the client_id and client_secret along with the refresh_token to get a new access token.
The grant_type also needs to be changed to refresh_token.
Where is the benefit of a refresh_token using this flow? If I need to pass the client_id and client_secret each time, surely you would just avoid using a refresh token altogether?
The issuance of a refresh token with the client credential grant has no benefit.
That is why the RFC6749 section 4.4.3 indicates A refresh token SHOULD NOT be included. Thus its issuance is at the discretion of the authorization server.
From my point of view an authorization server should never issue a refresh token with the client credentials grant as the access token issuance process will take an additional and unnecessary step:
The issuance of he access token with the client_credentials grant type is done on the first request.
The issuance of he access token with the refresh_token grant type is done after at least two requests, depending on the way you issued to first access token.
The benefit is that he request token normally has a much longer life span than the access token.
Access token is used in communicating with the resource server.
Request token is used when communicating with the authorization server.
You could read this as that you may be authorized but that the exact extend of your authorization needs to be reevaluated from time to time. So request token has it use.
I am new to OAuth and was wondering why authorization code is required?
Why authorization does not send access token or refresh token in callback response.
why not directly access token?
The Authorization Code grant uses the short-lived one-time code so that it can be exchanged for the real token (which is longer-lived and multiple-use) in a backchannel call that is more secure and can leverage credentials to authenticate the Client towards the Authorization Server.
The Implicit grant type returns the access token directly in the authorization response. It is considered to be more insecure because it is easier to attack (using crafted redirects etc.) and because there's no way to keep a client credentials secret.