I was decoding a JWT token via jwt.io (in the Debugger section) to see Headers, Payload. Surprisingly, it also verified, and I could see it (jwt.io debugger) is able to retrieve the public key as well.
So my question is: Does JWT token provide the public key as well as part of the JWT token?
I am pasting part of it (can't paste full due to security reasons, will be truncating part of the actual JWT token)
F3cy5jb21cL2V1LXdlc3QtMV9ZckVRYjY5Z1giLCJleHAiOjE2MDE2Mzg4OTMsImlhdCI6MTYwMTYzNTI5MywidmVyc2lvbiI6MiwianRpIjoiNmI2YmZiNmYtY2M0MS00N2Q5LWI0YzYtOTBmOGFmNWM2MjQ1IiwiY2xpZW50X2lkIjoiMTM0MWxxa3N1ZmUwbm1vaW9kdnRjc2t2cWIifQ.RtKfz54uBgSZ1gc4KRPjzL4dPe5AbH2YMJu-DDvIxBzgMjqT9q4ApGzcWYB62-MgDUf-F_hK0kF9eIwAi9fARhp 0HGGnyiuydW_our6zE3EphLvXQByTDY5xzOUuSvt7WbDZWeSfpHcjrBttRSJAPOsZ2gInafKjZgWKyGL4vJB9swEhOMSSpTQDGWKenJCyp4emhe8E4XGzYTo9WEb-Wqg6sI__LrusDNd917FaocPKBxA
Decoded messages (again truncated)
Headers
{
"kid": "cJ0PzkBXPyjX7FM67jcOECIY=",
"alg": "RS256"
}
Payload:
{
"sub": "13lqs0moiodvtcskvqb",
"token_use": "access",
"scope": "example.com/Manage",
"auth_time": 1601293,
"iss": "https://cognito.eu.amazonaws.com/",
"exp": 1601638,
"iat": 10353,
"version": 2,
"jti": "cc1-47d9-b6-5c6245",
"client_id": "nmodvtcb"
}
In there, can see the Public key (truncated)
-----BEGIN PUBLIC KEY-----
QEFAAOCAQ8AMIIBCxmf9bakWk
556KYmIZB+Sy1ftkkGa4qlUsmRvcG2Hll+7HBWp1ao6MVLskjdaaKg8iH1Iz4DKG
lgqT/ndwhoxvTBuvm0X2CZoNzZn4S8wDTr78m/S/YegZRhv6y58gkiKSEmbbC/g5
Bp+AF88NwBvLm1jdd
-----END PUBLIC KEY-----
Where from the debugger in jwt.io is retrieving the public key? I am not able to understand this.
The token contains the issuer (iss) of the token and the key id (kid), which identifies the public key that is needed to verify the signature
With this information, jwt.io can find the public key in form of a JWK (JSON Web Key) on a JWKS endpoint (/.well-known/jwks.json), to verify the token. A JWKS (JSON Web Key Set) contains an array of JWKs, the link shows an example.
According to the cognito documentation, this mechanism is used, when you use the Amazon user pool to authenticate your users.
Providing keys via a jwks endpoint is a standard mechanism which is also used by other providers, e.g. Microsoft Azure.
I've been trying to understand that myself too. If you open developer tools and see requests made by jwt.io when you paste the token in the debugger page you'll see it makes additional requests.
In my token the iss was:
"iss": "http://localhost:8080/auth/realms/myrealm"
hence jwt.io added the standard path /.well-known/openid-configuration and made XHR request to
http://localhost:8080/auth/realms/myrealm/.well-known/openid-configuration
Where it found a lot of information in json and among them there was jwks_uri
{
...
"jwks_uri": "http://localhost:8080/auth/realms/myrealm/protocol/openid-connect/certs",
...
}
And then there was another XHR request to the above url and response was jwks.
Having that public key the jwt.io could verify the token. At least that's what I think happens.
Related
I am using Oauth2+JWT+Spring security in one of my project. When i hit /outh/token using username/password i am receiving access token in the response with other details like
{
"access_token": <token>,
"token_type": <type>,
"refresh_token": <refresh-token>,
"expires_in":<secs>,
"scope": <scope>,
"jti": <value>
}
Is it possible to customize this response like
{
data: {
"access_token": <token>,
"token_type": <type>,
"refresh_token": <refresh-token>,
"expires_in":<secs>,
"scope": <scope>,
"jti": <value>
},
details:{
//extra information
}
}
I'm confused, don't know how to ask more clearly: "what is the additional data you want to send?". Just give an explicit sample.
I'll answer guessing that this data is related to the authorized entity (the user when answering within authorization-code flow and the client within client-credentials flow): non standard data should be set as private-claims, inside the JWT itself and on token introspection endpoint.
How to add such private claims depends on your authorization-server. For spring-security one, this is done with an OAuth2TokenCustomizer. For Keycloak, you have to provide a "mapper", etc.
The client which received a payload like the one you show, will only send the access-token when issuing requests to resource-server(s). It is important that this token holds all of the data needed for resources access decisions. Some claims are specified by OAuth2, OpenID defines some more standard claims, and you are free to put whatever additional data in private claims (within the limits of the maximum token size).
Also, if your client needs to read claims, it should use ID token, not access-token (request openid scope when initiating OAuth2 flow). Access-token should be interpreted by resource-server only.
I am learning about OAuth2 and OpenID Connect by experimenting with ASP.NET Core and IdentityServer4. So far I created a protected API server, an authorization server and a client by following a certain Udemy course. Things worked out well as client is able to get access token from the authorization server and use it to access protected API in the ASP.NET Core Web API project.
However, I am curious how can I manually validate JWT I get from my authorization server. The token I get is this:
eyJhbGciOiJSUzI1NiIsImtpZCI6IjdiMjM1NzYyMTRlOTg3ZjE3NTdjMWYxNDE1ZTg4OGEyIiwidHlwIjoiSldUIn0.eyJuYmYiOjE1NTMyNTYxNzMsImV4cCI6MTU1MzI1OTc3MywiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo1MDAwIiwiYXVkIjpbImh0dHA6Ly9sb2NhbGhvc3Q6NTAwMC9yZXNvdXJjZXMiLCJiYW5rT2ZEb3ROZXRBcGkiXSwiY2xpZW50X2lkIjoiY2xpZW50Iiwic2NvcGUiOlsiYmFua09mRG90TmV0QXBpIl19.boION1QMOxuHxgIkBT0hZchkCEzINSpIS20Az5HkkkkrbH72IHqC2u9tOQobCsPt4okSPIuKGmgsGY2oyPMNcQpZPAOivmKXknhij_lhTv7pzaSXmFFSSpih-eigk4243VkGz8fTH9vA_IHmQ59o9zv0Wva_pKBt9lBSd39BDocNblJR092VHl66gAp79iEJctDzEKBBdN_E-RCrgPPsetU_sO0wqgOuxA0wECAo_jQhPu3LkuU9sKfj2HAFGLVxwz0Is3SAg1XIXeZylivAJdXThMkVypjrFBTeehso_9g26MVY4bKCfZ5Bx75NmYUbOfpX1gLPSo0CWvTfHhwaNg
When I decode it on jwt.io website I get Header:
{
"alg": "RS256",
"kid": "7b23576214e987f1757c1f1415e888a2",
"typ": "JWT"
}
and Payload:
{
"nbf": 1553256173,
"exp": 1553259773,
"iss": "http://localhost:5000",
"aud": [
"http://localhost:5000/resources",
"bankOfDotNetApi"
],
"client_id": "client",
"scope": [
"bankOfDotNetApi"
]
}
Since I used RS256 algorithm for signing I need to add public key to the jwt.io to verify the token. But where do I get this public key?
If I go to discovery endpoint of my auth server (eg. http://localhost:5000/.well-known/openid-configuration/jwks) I get following data:
{
keys: [
{
kty: "RSA",
use: "sig",
kid: "7b23576214e987f1757c1f1415e888a2",
e: "AQAB",
n: "509tIiUvmKkjjGOwzKElduRqpRND7YO-Op-IlsAeNwTlxY9_t22XfCqmxUyNvuvmdIVYXz-utl5bee3Tjwp8e7ok-Vn2uX-nI0jBcjTIKL0arbd7Qo5XgvICU4x-UcINrHtqMnY4S_R0uMKgaJkl3105bh9svQh--65tknjiKqmefT4M5SLHStWTisy2e0YwiaqvLam-O_rtbEawMy5-4avZep33y9Wz_JlgWyQ4jKD1Kn8mNGybjRoW3FJRkqzVNUSrGzjqwdDPL1cZOzM2HnbBqwVSFNnJiRYxPxKL_N8Q4CS9e2OVRjTof_EdzTTGC5mkOPhBCjpmvYS5d0j6JQ",
alg: "RS256"
}
]
}
But which of these is public key? I tried pasting values for n, e and kid to jwt.io page under public key textfield in the "verify signature" section, but I always get "Invalid signature" error.
So how do I get public key for RS256 token from discovery endpoint and how can I use it to validate token in manually in jwt.io website?
Put there the whole (first and only) keys object value, including curly brackets, at least the following:
{
"kty":"RSA",
"kid":"7b23576214e987f1757c1f1415e888a2",
"e":"AQAB",
"n":"509tIiUvmKkjjGOwzKElduRqpRND7YO-Op-IlsAeNwTlxY9_t22XfCqmxUyNvuvmdIVYXz-utl5bee3Tjwp8e7ok-Vn2uX-nI0jBcjTIKL0arbd7Qo5XgvICU4x-UcINrHtqMnY4S_R0uMKgaJkl3105bh9svQh--65tknjiKqmefT4M5SLHStWTisy2e0YwiaqvLam-O_rtbEawMy5-4avZep33y9Wz_JlgWyQ4jKD1Kn8mNGybjRoW3FJRkqzVNUSrGzjqwdDPL1cZOzM2HnbBqwVSFNnJiRYxPxKL_N8Q4CS9e2OVRjTof_EdzTTGC5mkOPhBCjpmvYS5d0j6JQ"
}
I'm using Okta for identity management. As the client in authorization flow, I send an authorize request to Okta. This works successfully, and I get a JWT payload. I want to verify the JWT signature, so I make another call to Okta in order to fetch the keys. However, the key ids (kids) do not match and verification fails.
Initial authorize request:
https://{{site}}.okta.com/oauth2/v1/authorize
?scope=openid
&response_type=id_token
&client_id={{client_id}}
&redirect_uri={{redirect_url}}
&nonce=4euiv0v52at3la15e7qlu1mt43
&state=7c92bqulrmdk2jk0ro9rd3mf5j
Response is a 403, redirecting me to:
{{redirect_url}}/id_token={{id_token}}
The header of the id_token is decoded into:
{
"alg": "RS256",
"kid": "2YKtkekCjCRWN0YqGsjUrNwIQaxGg5ahfHW0_fK8t64"
}
So far so good. I know that the authorization has succeeded. Time to validate the JWT.
However, when this is followed up with:
https://{{site}}.okta.com/oauth2/v1/keys
Or
https://{{site}}.okta.com/oauth2/v1/keys?clientId={{client_id}}
(they both return the same response), I get back this:
{
"keys": [
{
"alg": "RS256",
"e": "AQAB",
"n": "gv1rI9A7mrOoViJZTzUfiZl7YdEzLEofvRoVbXCgeW7aOmoKcAkWGHvqNRGoFgi8auV5b_TSgTXKq_TV1fz643hpAtba3V0Uw2lXchTbqXpmVRYXI1t4FIwRMXLe4Q-kcvp9la21e3D1lszjdPbFNX5GLAhrCW0Thu2HYbTLg6TbDTMaiQCMo15hek0JgZqRGzCkt9kINnwPVLXV_bkSh_fHWo_6G1L0MKYYQcgE6zvPlULLek98-yZ6Nlg6nJUY9nHn0qjhzqqq-bz_Vin8qi3Bt7SjUKwk7HbaugM84AEgDxYE5JgsaALIl5SgIc3GgFEc69qKWymoD-w1a8f1HQ",
"kid": "SOxFkBSLWefjlZoDI49Hk0nqlYtC28cjhTlVAYEzAxs",
"kty": "RSA",
"use": "sig"
}
]
}
Where the kid does not match what I received in the original response.
Where is my mistake?
You need to create an authorization server and use it as the endpoint, for example:
https://{{site}}.okta.com/oauth2/{authorizationServerId}/v1/authorize
You should also be able to use the default one:
https://{{site}}.okta.com/oauth2/default/v1/authorize
Note that this is different than the route you were using (which does not specify an authorization server):
https://{{site}}.okta.com/oauth2/v1/authorize
You should specify an authorization server in your case (like example 1 and 2 above), for both OAuth 2.0 and OpenID Connect.
The problem was that this account was setup with pinned, not rotating keys. oauth2/v1/keys requires the client id to be passed in as a parameter if you are setup with pinned keys; the correct parameter name is "client_id", not "clientId." This results in the expected output.
When doing cross platform authentication, you can get an ID token from your Android app using the GoogleApiClient, which you can give to your backend server. The server will then first verify the token using the following url:
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123
If the token is properly signed and the iss and exp claims have the expected values, you will get a HTTP 200 response, where the body contains the JSON-formatted ID token claims. Here's an example response:
{
"iss": "https://accounts.google.com",
"sub": "110169484474386276334",
"azp": "1008719970978-hb24n2dstb40o45d4feuo2ukqmcc6381.apps.googleusercontent.com",
"email": "billd1600#gmail.com",
"at_hash": "X_B3Z3Fi4udZ2mf75RWo3w",
"email_verified": "true",
"aud": "1008719970978-hb24n2dstb40o45d4feuo2ukqmcc6381.apps.googleusercontent.com",
"iat": "1433978353",
"exp": "1433981953"
}
What does all these fields mean aside from email?
Claims contains a set of name/value pairs
iss: The issuer of the token
sub: The subject of the token.An identifier for the user, unique among all Google accounts and never reused.
azp: The client_id of the authorized presenter.
at_hash: Access token hash. Provides validation that the access token is tied to the identity token.
email_verified: True if the user's e-mail address has been verified; otherwise false.
aud: Identifies the audience that this ID token is intended for. It must be one of the OAuth 2.0 client IDs of your application.
iat: The time the ID token was issued, represented in Unix time (integer seconds).
exp: The time the ID token expires, represented in Unix time (integer seconds).
See: https://developers.google.com/identity/protocols/OpenIDConnect
for more details.
When a client asks a resource server to get a protected resource with an OAuth 2.0 access token, how does this server validate the token? The OAuth 2.0 refresh token protocol?
Google way
Google Oauth2 Token Validation
Request:
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
Respond:
{
"audience":"8819981768.apps.googleusercontent.com",
"user_id":"123456789",
"scope":"https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
"expires_in":436
}
Microsoft way
Microsoft - Oauth2 check an authorization
Github way
Github - Oauth2 check an authorization
Request:
GET /applications/:client_id/tokens/:access_token
Respond:
{
"id": 1,
"url": "https://api.github.com/authorizations/1",
"scopes": [
"public_repo"
],
"token": "abc123",
"app": {
"url": "http://my-github-app.com",
"name": "my github app",
"client_id": "abcde12345fghij67890"
},
"note": "optional note",
"note_url": "http://optional/note/url",
"updated_at": "2011-09-06T20:39:23Z",
"created_at": "2011-09-06T17:26:27Z",
"user": {
"login": "octocat",
"id": 1,
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"gravatar_id": "somehexcode",
"url": "https://api.github.com/users/octocat"
}
}
Amazon way
Login With Amazon - Developer Guide (Dec. 2015, page 21)
Request :
https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR...
Response :
HTTP/l.l 200 OK
Date: Fri, 3l May 20l3 23:22:l0 GMT
x-amzn-RequestId: eb5be423-ca48-lle2-84ad-5775f45l4b09
Content-Type: application/json
Content-Length: 247
{
"iss":"https://www.amazon.com",
"user_id": "amznl.account.K2LI23KL2LK2",
"aud": "amznl.oa2-client.ASFWDFBRN",
"app_id": "amznl.application.436457DFHDH",
"exp": 3597,
"iat": l3ll280970
}
Update Nov. 2015: As per Hans Z. below - this is now indeed defined as part of RFC 7662.
Original Answer: The OAuth 2.0 spec (RFC 6749) doesn't clearly define the interaction between a Resource Server (RS) and Authorization Server (AS) for access token (AT) validation. It really depends on the AS's token format/strategy - some tokens are self-contained (like JSON Web Tokens) while others may be similar to a session cookie in that they just reference information held server side back at the AS.
There has been some discussion in the OAuth Working Group about creating a standard way for an RS to communicate with the AS for AT validation. My company (Ping Identity) has come up with one such approach for our commercial OAuth AS (PingFederate): https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=lzn1564003025072.html#lzn1564003025072__section_N10578_N1002A_N10001. It uses REST based interaction for this that is very complementary to OAuth 2.0.
An update on #Scott T.'s answer: the interface between Resource Server and Authorization Server for token validation was standardized in IETF RFC 7662 in October 2015, see: https://www.rfc-editor.org/rfc/rfc7662. A sample validation call would look like:
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer 23410913-abewfq.123483
token=2YotnFZFEjr1zCsicMWpAA
and a sample response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"active": true,
"client_id": "l238j323ds-23ij4",
"username": "jdoe",
"scope": "read write dolphin",
"sub": "Z5O3upPC88QrAjx00dis",
"aud": "https://protected.example.net/resource",
"iss": "https://server.example.com/",
"exp": 1419356238,
"iat": 1419350238,
"extension_field": "twenty-seven"
}
Of course adoption by vendors and products will have to happen over time.
OAuth 2.0 spec doesn't define the part. But there could be couple of options:
When resource server gets the token in the Authz Header then it calls the validate/introspect API on Authz server to validate the token. Here Authz server might validate it either from using DB Store or verifying the signature and certain attributes. As part of response, it decodes the token and sends the actual data of token along with remaining expiry time.
Authz Server can encrpt/sign the token using private key and then publickey/cert can be given to Resource Server. When resource server gets the token, it either decrypts/verifies signature to verify the token. Takes the content out and processes the token. It then can either provide access or reject.
Updated Answer for 2021
It is generally not recommended that you roll any part of the OAuth 2 / OIDC implementation on your own, especially now that token introspection is part of the standard. Much like attempting to roll your own encryption library, it is far too easy to make critical mistakes with such a complex spec.
Here's a list of recommended libraries in other languages that implement OAuth 2. Here's another of ones that have been certified by the OpenID Foundation; many of those libraries also implement OAuth 2.
If you're in .NET and using the IdentityServer library (version 2.2 and up), the introspect endpoint accomplishes exactly this. It's published as part of the discovery document (also standard), and is an endpoint against which the resource server can validate access tokens.
If you've come this far and you still really want to roll your own, take some tips from how the bigger libraries have done it.
OAuth v2 specs indicates:
Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications.
My Authorisation Server has a webservice (SOAP) endpoint that allows the Resource Server to know whether the access_token is valid.