I'm new using JWTs. I have an API that generates a JWT for the clients to be authenticated for further requests. My JWT has a property that returns the user id:
{
jwt: {
exp: "2017-12-12 00:00:00",
data: {
user_id: 491
}
}
}
My question is if the client can decode the JWT generated by the API and add a new property into the data field, like this:
{
jwt: {
exp: "2017-12-12 00:00:00",
data: {
user_id: 491,
status: 1
}
}
}
Or, if I can generate the JWT from the API auth system with the status field set to a default value and then the client could change it.
Thank you.
The client can do that, but it would make the token invalid. When you change the content of the payload, e.g. add another field or change its content, the signature of the token no longer matches. When the API receives a token with invalid signature it should reject the token. Imagine if you had a field called isAdmin and the client could change it from false to true. It would make your authentication pointless; the client doesn't decide whether it's admin or not, the backend does.
When the token's payload changes the signature has to be remade. In order to sign the token, the client has to know the secret key (for H256). But the client shouldn't know the secret key.
So the answer is no, the client can't change the token.
You can read more about that here.
In other words, you want to tamper with your JWT token and you cannot do it without invalidating the token.
The signature is calculated over the header and over the payload. The token issuer (the server) checks the signature to verify that the content has not been changed along the way.
In the latest Version of JWT Auth
$token = JWTAuth::claims(['account_id' => $account->id])->fromUser($user);
to data from token :
$payload = JWTAuth::getPayload();
$accountId = $payload->get('account_id');
in the preview version of JWT auth
$token = JWTAuth::fromUser($user, ['account_id' => $account->id]);
to data from token :
$payload = JWTAuth::getPayload(JWTAuth::getToken());
Related
I was looking at the section about Self-issued OpenID Provider Response, where they describe a method of validation, where the public key is included in the token itself. They use this as an example token:
{
"iss": "https://self-issued.me",
"sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
"aud": "https://client.example.org/cb",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"e":"AQAB"
}
}
I get how you can use the appended key for validation. But I don't get what prevents someone from using a fake key-pair to create a similar token. The only way I see this happening is if the public key is known by the validator from somewhere else, but in that case it doesn't make a lot of sense to include it in the token.
How does this work?
The way this work is that the hackers don't have access to the private key that was used to sign the token signature. The public key is derived from the private key.
The public key is safe to distribute as it only verifies the token signature. T
I don't think it's that common to include the public key inside the token as the token size gets bigger. Instead, you, as a receiver, download it separately, or it is provided to you some other way.
The picture below gives a summary of how public-key cryptography works.
But I don't get what prevents someone from using a fake key-pair to create a similar token.
Given the validations in Self-Issued ID Token Validation there is no feasible way for "someone" to sign a token which would have the same sub (JWT Subject). Of course they may sign a Token which would pass validations, but ONLY for a different subject. So IF you choose to accept Self-Issued ID Tokens, the guarantee you get is that you can re-identify the same Subject. That's kind of the whole point, Self-Issued OpenID providers are personal wallets, given the cryptography present in the flow you can be sure a given returned subject is the same one you encountered prior as long as sub is the same as before (or one that you know and have established trust with OOB).
Node.js code as a reference:
import * as assert from "node:assert";
import * as jose from "jose";
let jwt;
const redirect_uri = "https://rp.example.com/siop/cb";
const nonce = "n-0S6_WzA2Mj";
{
// this is unreachable by the party verifying
const kp = await jose.generateKeyPair("ES256");
const sub_jwk = await jose.exportJWK(kp.publicKey);
jwt = await new jose.SignJWT({ sub_jwk, nonce })
.setSubject(await jose.calculateJwkThumbprint(sub_jwk))
.setIssuer("https://self-issued.me")
.setAudience(redirect_uri)
.setProtectedHeader({ alg: "ES256" })
.setExpirationTime("5m")
.setIssuedAt()
.sign(kp.privateKey);
}
const verified = await jose.jwtVerify(
jwt,
async (protectedHeader, token) => {
const { sub_jwk, sub } = JSON.parse(
new TextDecoder().decode(jose.base64url.decode(token.payload))
);
assert.equal(sub === (await jose.calculateJwkThumbprint(sub_jwk)), true);
const key = await jose.importJWK(sub_jwk, protectedHeader.alg);
assert.equal(key.type, "public");
return key;
},
{
audience: redirect_uri,
issuer: "https://self-issued.me",
}
);
assert.equal(verified.payload.nonce, nonce);
console.log(verified);
Received access token from AAD, using below url
https://login.microsoftonline.com/gdfdddddd-87dd-497c-b894-xxxxxx/oauth2/v2.0/token
grant_type :client_credentials
client_id :xxxxx-1ff5-4615-8d71-yyyyyy
client_secret:[7aCw]fdsfsfsfds.AC61Fg:cm33
scope : https://vault.azure.net/.default
Validated the above received token using below code manually & it works fine
IConfigurationManager<OpenIdConnectConfiguration> configurationManager = new ConfigurationManager<OpenIdConnectConfiguration>("https://login.microsoftonline.com/TestDomain310320.onmicrosoft.com/v2.0/.well-known/openid-configuration", new OpenIdConnectConfigurationRetriever());
OpenIdConnectConfiguration openIdConfig = AsyncHelper.RunSync(async () => await configurationManager.GetConfigurationAsync(CancellationToken.None));
TokenValidationParameters validationParameters =
new TokenValidationParameters
{
ValidIssuer = "https://sts.windows.net/a3d2bff3-87dd-497c-b894-f63befdd7496/",
ValidAudiences = new[] { "https://vault.azure.net" },
IssuerSigningKeys = openIdConfig.SigningKeys
};
SecurityToken validatedToken;
JwtSecurityTokenHandler handler = new JwtSecurityTokenHandler();
var user = handler.ValidateToken(token, validationParameters, out validatedToken);
Modified parameter Scope:https://graph.microsoft.com/.default & received AAD token successfully but token validation using above code fails with error message "IDX10511: Signature validation failed. Keys tried: '[PII is hidden]'." Verified AAD app with above mentioned client id is having "user.read/user.read.basicall permissions". Why token validation fails if tokens are received from AAD with Scope:https://graph.microsoft.com/.default
Observation:
Token received with scope : https://vault.azure.net/.default
{
"typ": "JWT",
"alg": "RS256",
"x5t": "YMELHT0gvb0mxoSDoYfomjqfjYU",
"kid": "YMELHT0gvb0mxoSDoYfomjqfjYU"
}
While token received with Scope:https://graph.microsoft.com/.default has extra nonce property to avoid replay attack, is it be the reason for token validation failure?
{
"type": "JWT",
"nonce": "wCXLm9rF5Nma2S7OswU44uAVRpVbM_20WrWJkqbWe6Y",
"alg": "RS256",
"x5t": "YMELHT0gvb0mxoSDoYfomjqfjYU",
"kid": "YMELHT0gvb0mxoSDoYfomjqfjYU"
}
please suggest.
You should not be looking into, or validating tokens that were not issued to your own Apis. The intended receiver, KeyVault and MS Graph will do the necessary validation themselves. You should treat these Access Tokens as an opaque blobs that you stuff into the Authorization header in your calls to these Apis.
An Api owner, Graph or KeyVault can tomorrow can change the claims present in them or even choose to encrypt their tokens and your code will break.
Why are you validating tokens? If you are reading validated tokens of Apis that do not belong to you in your applications as a proof of Authentication, then you are setting yourself up for failure. Also its a security concern as any app in the world which can obtain an Access token for KeyVault or MS graph can pass it your Apis and compromise it.
Here is a discussion for reference - Cannot validate signature. #609
Yes, the error was caused by the nonce field in JWT header.
As far as I know, if we request the access token of graph api, the JWT token will contain the nonce field. And then we can't validate it on our backend(For security reasons, microsoft doesn't allow us to do this operation).
I am using the Passport AAD project with the bearer strategy to protect my endpoints. After I receive tokens with the OIDC strategy when logging in, I can't seem to get the bearer strategy to validate the signature of the access token. I get:
authentication failed due to: invalid signature
I have no problems validating the id_token, but I would prefer not to use this for our client app if the id_token can't be refreshed with AAD. Also, when using jwt.io to test the validation with the published public keys, I see the same issue (can validate the id_token, but not the access_token).
Am I missing a step when grabbing the access token, or is there a gap in my understanding of how access tokens are validated?
Update with more details
I am requesting an access token from my tenant:
identityMetadata: https://login.microsoftonline.com/your_tenant_name.onmicrosoft.com/.well-known/openid-configuration,
responseType: 'id_token code'
Using the OIDCStrategy in the AAD Passport project.
const callbackOIDC = (iss, sub, profile, accessToken, refreshToken, params, done) => {
return done(null,{
profile,
accessToken,
refreshToken
});
};
passport.use(new OIDCStrategy(config.creds, callbackOIDC));
Then I run authenticate, shown below:
auth.adCallback = function (req, res, next) {
passport.authenticate('azuread-openidconnect', {
response: res,
resourceURL: 'https://graph.microsoft.com',
session: false
}, function (err, user, info) {
console.log(user.access_token);
})(req, res, next);
};
I think I may have been asking for a graph access token above by specifying the resource URL. If I remove that resource URL, I still get an access token, but the bearer strategy throws an invalid token error (instead of an invalid signature error). Is there a different resource URL I should be setting to match with my tenant and get the access token I'm looking for?
What access tokens are you requesting? If the access token is meant to be used against the Microsoft Graph, for example, it is the Graph's task to validate them- not your app's.
Can you expand on the exact scenario you are trying to implement, and at what point you need to refresh id_tokens?
I'm using the google HTML sign-in button in my single page (javascript) application to obtain an authorization object from users with Google logins. This is detailed here: https://developers.google.com/+/web/signin/add-button.
I successfully receive back a token such as shown below. Since this token expires in 1 hour, I need to refresh the token every 30 minutes or so, until the user choses to log out. I am attempting this by calling:
gapi.auth.authorize({client_id: "90... ...92.apps.googleusercontent.com", scope: "profile email", immediate: true}, function() { console.log( arguments ); } );
but with no luck. I receive the same token back until it expires, after which I get back the empty (not signed in) token. How can I preserve / refresh the bearer token without the user having to continually log in again?
{
_aa: "1"
access_token: "ya29.1.AA... ...BByHpg"
authuser: "0"
client_id: "90... ...92.apps.googleusercontent.com"
code: "4/Nyj-4sVVcekiDnIgMFh14U7-QdRm.svPMQSODiXMbYKs_1NgQtmX9F90miwI"
cookie_policy: "single_host_origin",
expires_at: "1398341363",
expires_in: "3600",
g_user_cookie_policy: undefined,
id_token: "eyJhbGciOiJ... ...0Es1LI"
issued_at: "1398337763",
num_sessions: "2",
prompt: "none",
response_type: "code token id_token gsession",
scope: "https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
session_state: "b92d67080... ...73ae",
state: "",
status: {
google_logged_in: true,
method: "AUTO",
signed_in: true
},
token_type: "Bearer"
}
Using the client side flow (ie Java Script) you can only receive short-lived (~1 hour) access_token. If you want to be able to refresh it, you need a refresh_token which can only be obtained using the server side flow.
You can find more information here.
Basically,it works like this :
The user connects to your Website and clicks on the "Sign-in button"
You receive an access_token and a code in JavaScript
You send this code to a PHP Script on your web server
The script makes a request to Google Servers and exchanges your code for an
access_token(which should be identical to the one you just received in JavaScript) and a refresh_token
You need to store this refresh_token somewhere (in a data base for
example) because it will only be issued once (when the users grants
permission)
When one of your access_token is about to expire, you can use your
refresh_token to get another valid access_token
As well as setting a timer, you should check that your token is still valid before making the API call. Now that the client library returns promises, and promises are chainable, you can do it really elegantly.
See my gist here.
I just got the following result when I tried to do oauth2 to googleapi. Only one thing: I couldn't find what is id_token used for in documentation.
{
"access_token": "xxxx",
"token_type": "Bearer",
"expires_in": 3600,
"id_token": "veryverylongstring",
"refresh_token": "abcdefg"
}
id_token is a JSON Web Token (JWT). If you decode it, you'll see it contains multiple assertions, including the ID of the user. See this answer for more details.
The id_token is used in OpenID Connect protocol, where the user is authenticated as well as authorized. (There's an important distinction
between authentication and authorization.) You will get id_token and access_token.
The id_token value contains the information about the user's authentication. The ID token resembles the concept of an identity card, in a standard JWT format, signed by the OpenID Provider (OIDP). To obtain one, the client needs to send the user to their OIDP with an authentication request.
Features of the ID token:
Asserts the identity of the user, called subject in OpenID (sub).
Specifies the issuing authority (iss).
Is generated for a particular audience, i.e. client (aud).
May contain a nonce (nonce).
May specify when (auth_time) and how, in terms of strength (acr), the user was authenticated.
Has an issue (iat) and expiration time (exp).
May include additional requested details about the subject, such as name and email address.
Is digitally signed, so it can be verified by the intended
recipients. May optionally be encrypted for confidentiality.
The ID token statements, or claims, are packaged in a simple JSON object:
{
"sub" : "alice",
"iss" : "https://openid.c2id.com",
"aud" : "client-12345",
"nonce" : "n-0S6_WzA2Mj",
"auth_time" : 1311280969,
"acr" : "c2id.loa.hisec",
"iat" : 1311280970,
"exp" : 1311281970
}