I'm currently working on configuring Keycloak as a federated identity provider to test the OIDC back-channel logout flow.
In both id token and the logout token, they don't include the sid claim by default since it is an optional claim. But in the client's configuration, there's a config to enable the session identifier in the back-channel logout token. Config to enable 'sid' claim. If this is enabled, the logout token will have an sid claim, but the id token won't.
OIDC Specification section 2.1,
backchannel_logout_session_supported:
OPTIONAL. Boolean value specifying whether the OP can pass a sid (session ID) Claim in the Logout Token to identify the RP session with the OP. If supported, the sid Claim is also included in ID Tokens issued by the OP. If omitted, the default value is false.
According to this, if the sid claim is included in the logout token, id token should also have the sid claim
Is there a way to include sid claim in the id token as well ?.
If not, what's the purpose of having an sid claim only in the logout token and not in the id token ?
I'm not familiar with the back-channel flows, but in general you want to use KeyCloak's concept of "Mappers" to add claims into tokens. Both Identity Providers and Clients can have Mappers, depending on where you need to add data.
Clients and IdP configs will have different 'Mapper Types' available. The 'Mapper Type' field is the most important field when configuring the Mapper - it determines where the data is coming from (some session value, some user attribute, etc). We often have to write small custom implementations for new mapper types to pull some data out of the Java layer so we can put it into a token.
Related
I just realized that the userinfoendpoint doesn't give any useful info about the logged in user.
Now, I saw that you can get an id_token from ADFS tokenendpoint. This id_token is actually a JWT which contains the unique_name.
Now my question is, if it is safe to use this info without signature validation (since we don't have the private key of the HS256 algorithm and validation is as far as I understood, a thing for the issuer not for the client).
• There are two scenarios to your question of whether it is safe to use this info from an ID_token. First, your client, i.e., the application or authorization server will validate the token just like it validates the access token for any tampering. Also, it can validate the issuer to ensure that the correct issuer has sent back the token. Since there are many libraries to validate an ID token, you should use them for ID token validation purposes.
• Also, only confidential client applications should validate an ID token as their token holds a secret while public applications don’t benefit from validating an ID token as there is always a risk of a malicious user who can intercept and edit the keys used for validation of the token.
• As you are speaking of the case when you don’t have the private key to the algorithm used for encrypting the ID token, it must be a confidential client application. Thus, validating the ID token on the lines of access token and confirming the below claims are validated by your token validation library, you can then use the information retrieved from these claims for your purpose. The claims that need to be validated are as follows: -
Timestamps: the iat, nbf, and exp timestamps should all fall before or after the current time, as appropriate.
Audience: the aud claim should match the app ID for your application.
Nonce: the nonce claim in the payload must match the nonce parameter passed into the /authorize endpoint during the initial request.
Please find the below documentation link for more in-depth details on validating the tokens and the inherent process involved in it: -
https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validating-tokens
No, sadly the userinfo endpoint only gives you a "sub".
You can validate the JWT yourself.
You should always check the signature.
I've been developing my first REST API to serve as the back-end for a mobile application. I'm pulling info from different resources, and am a little confused when it comes to the token implementation (I'm using JWT).
The access token is used to ensure that the requester has access to the resource that is being called. My understanding is that I will then encode the user details in the ID Token, such that the relevant information can be returned. The refresh token is used as a security mechanism, to keep the user authenticated after the short-lived ID and access tokens expire.
The access token seems a little redundant, and maybe it is an interchangeable term for ID token? Can I just remove that part from my authentication scheme?
In the proposed scheme access and ID tokens are used interchangeably and do not provide any value over the other. All information provided in the access token can be stored in the ID token, or vice versa. The entire authentication scheme will then simply consist of an access token (containing both info on access permissions, and user info), and a refresh token (ensuring that users don't need to login again every t minutes).
The Kubernetes documentation related to OpenID Connect mentions that as part of setting things up you need to supply some parameters to the API server:
--oidc-client-id: A client id that all tokens must be issued for.
There is no other explanation about how this would map to, say, something returned by the OpenID Connect-conformant Google identity provider.
I don't know what this parameter value will be used for. Will it match against something in the decoded JWT token?
It looks like the id_token returned by the Google identity provider might contain something, once decoded, in its aud field (aud is apparently short for "audience"). Is this what the --oidc-client-id should match? Am I way off?
This can be explained from the kubernetes documentation on id tokens.
As you can see, identity provider is a separate system. For example this can be MS Azure AD or Google as you have shown.
When you register for a identity provider, you get important things in return. client id is one such important parameter. if you are aware of the openid connect flow, you need to provide this client id when you follow the flow. If the flow is complete, you will return an id token. An id token has one must have claim, aud which is the audience that token was issued for.
When you validate an id token you MUST verify you are in the audience list. More can be found from the spec.
Quoting from specification,
The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience
Now, kubernetes uses bearer tokens. Here the tokens used are id tokens. To validate the token it should know specifically the audience. This enables the API server to validate the token is issued for the particular client who made the call. Thus authorising the call to to success.
I am implementing a user service that is storing user info in Azure Table storage. I would like to use a value for tenant ID as part of my partition key, but, the claims available in GetProfileDataAsync and IsActiveAsync are just 5 built in claims (sub, name, amr, idp, auth_time).
I get tenant ID from my identity provider and it's included as a claim in both my access token & identity token. How can I make it available to those methods?
When the AuthenticateLocal is invoke, you return an AuthenticateResult to indicate the authentication outcome. If it's successful you use the ctor overload that accepts the subject and name values. There's also an optional claims collection. If you pass values for claims then you are adding your own custom claims to the authentication cookie at IdentityServer. Those claims are then part of the Subject for the GetProfile API (assuming the requests into those APIs are being done via the browser such as from the authorization request). You can then inspect those claims and use them in any way you want.
If the request is not via the browser, then the only claim you have on the Subject is the user's unique id (which is the sub claims).
I am generting a jwt for an api token. I am putting the user id into that jwt so I know who is calling into the api. Where do I put the user id in the jwt.
I have seen many different examples that put it in 'sub', 'aud' and even 'iss'. Which is correct if any. Or does user id go in a non registered name?
The sub claim is the right claim for the user identifier. The aud claim identifies the intended recipient of the JWT and the iss identifies the issuer/creator. Any other interpretations of these claims are not standard compliant, see: https://www.rfc-editor.org/rfc/rfc7519#section-4.1