From this page: https://www.pingidentity.com/en/company/blog/posts/2019/jwt-security-nobody-talks-about.html:
The fourth security-relevant reserved claim is "iss." This claim indicates the identity > of the party that issued the JWT. The claim holds a simple string, of which the value is > at the discretion of the issuer. The consumer of a JWT should always check that the > "iss" claim matches the expected issuer (e.g., sso.example.com).
As an example, in Kubernetes when I configure the kubernetes auth like this for using a JWT for a vault service account (from helm), I no longer get an ISS error when accessing the vault:
vault write auth/kubernetes/config \
token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
kubernetes_host="https://$KUBERNETES_PORT_443_TCP_ADDR:443" \
kubernetes_ca_cert=#/var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
issuer="https://kubernetes.default.svc.cluster.local"
But what does this URL mean? Is it a somewhat arbitrary string that was set when the JWT was generated?
JWT token issuer - is the party that "created" the token and signed it with its private key.
Anyone can create tokens, make sure that the tokens you receive is created by a party that you trust.
Related
Added a custom claim by navigating to WSO2 v5.11 IS console and navigating to Claims -> Add -> Add Local Claim. as shown below
New User created in WSO2 and profile updated with custom claims as shown below
Invoke published end point from Java client to get the JWT Token from request headers as shown below.
jWTToken = httpRequest.getHeader("X-JWT-Assertion");
JWT Token retrieved successfully from request headers.
After decoding the token we are seeing only default claims not the custom claims.
We are expecting the JWT token should return custom claims along with default claims.
Is there any configuration required in WSO2 5.11.0 to get the custom claims with JWT token?
Environment
WSO2 IS 5.11.0
WSO2 API Manager 4.1.0
Expectation
JWT Token should return custom claims
If you want to add the custom claims to your generated JWT tokens, you need to mark the claims in the service provider configuration as mandatory of the particular application you are using to generate the token.
Refer https://is.docs.wso2.com/en/5.10.0/learn/configuring-claims-for-a-service-provider/#claim-mapping for more details.
Then you need to add the openid scope when invoking the token endpoint.
curl -k -d "grant_type=password&username=<USERNAME>&password=<PASSWORD>&scope=openid" -H "Authorization: Basic <BASE64 ENCODED CONSUMER_KEY:CONSUMER_SECRET>, Content-Type: application/x-www-form-urlencoded" https://<GATEWAY_HOSTNAME>:<PORT>/token
Refer https://apim.docs.wso2.com/en/latest/design/api-security/openid-connect/obtaining-user-profile-information-with-openid-connect/ for more details.
Then the custom claim will be added to the token, and will be passed to the generated backend JWT token as well.
I am setting up JWT auth method for Hashicorp Vault and want to check if the token that is being passed has correct audience, issuer and scope.
For audience and issuer it is easy and I can follow documentation:
vault write auth/jwt/config default_role="myrole"
oidc_discovery_url="URL"
bound_issuer="MY_ISSUER"
vault write auth/jwt/role/myrole user_claim="sub"
groups_claim="groups"
policies="my-policy"
role_type="jwt"
bound_audiences="MY_AUDIENCE"
Is it possible to have a "bound_scp" somehow?
Vault supports logging in using a JWT. I have a proxy in front of my Vault instance which manages an OIDC flow and injects a JWT as a bearer token in the Authorization header.
Instead of being presented with the Vault login screen, it would be convenient if Vault could parse the Authorization header and automatically log me in -- is this possible?
I know Vault supports Vault tokens in the Authorization header, but since I access my other dashboards using this JWT, it would be powerful for Vault to also interpret it.
As far as i know: no, not in the usual way with http-header authorization.
Vault would accept the jwt-token from oidc for login if the jwt-token comes as body/payload in json like this:
POST /v1/auth/jwt/login
{"jwt":"YOUR.JWT.TOKEN"}
Like written in vault docs:
curl --request POST \
--data '{"jwt": "YOUR.JWT.TOKEN", "role": "demo"}' \
http://127.0.0.1:8200/v1/auth/jwt/login
As header vault accepts the http-header X-Vault-Token: s.XYZYXr3kuxR4, which is a vault-token and not the oidc-jwt-token
Currently, I am connecting to a corporate vault service where I am using a vault token and passing it through below header in my spring cloud config service where properties of all microservices are kept.
curl -X "GET" "http://localhost:8080/my-client-microservice/dev" -H "X-Config-Token: s.myvaulttoken"
where http://localhost:8080 is my spring cloud config service and s.myvaulttoken is my vault token. This is working absolutely fine.
I want to know the validity of this token. What I have read the documentation that token can be of two type: service or batch. I want to know whether this token can be used infinitely (as root tokens validity is infinite).
Since the client microservices require the vault token, I want to figure out the way to know the validity of a token. Can you guys help me to tell more about this?
I followed this link: https://learn.hashicorp.com/vault/getting-started/authentication
Every non-root token has a time-to-live (TTL) associated with it.
For example:
with a root token, the ttl is 0
vault token lookup -format json | jq .data.ttl
0
with a regular user, the ttl is non-zero
VAULT_TOKEN=$(vault token create -policy default -field token) vault token
lookup -format json | jq .data.ttl
2764799
This check is possible through the API as well.
I have a server application that receives a user access token from the client and generates an appsecret_proof. I would like to make a graph API call in order to verify that the received access token is valid:
curl \
-F 'access_token=<my access token>' \
-F 'appsecret_proof=<my appsecret_proof>' \
https://graph.facebook.com/me
However, when I omit the appsecret_proof field the request is still verified. In both cases the response is:
{"success":true}
If I intentionally pass an invalid appsecre_proof it works as expected:
{"error":{"message":"Invalid appsecret_proof provided in the API argument","type":"GraphMethodException","code":100}}
I have made the neccessary changes in the Advanced settings:
According to the Facebook documentation: "When this is enabled, we will only allow API calls that either include appsecret_proof or are made from the same device the token was issued to."
"Once you've changed that setting, an attacker will not be able to use stolen access tokens without access to your app secret."
What am I missing here?
appsecret_proof is not same as the APP SECRET KEY.
Based on FB documentation, this is how it needs to be obtained:
go to http://www.freeformatter.com/hmac-generator.html#ad-output
in the message area, put the access token
in the secret key, put the APP secret key
Choose SHA256 as the digest algorithm
Generate the HMAC
You can use this generated HMAC as the my appsecret_proof in (for example):-
curl \
-F 'access_token=<my access token>' \
-F 'appsecret_proof=<my appsecret_proof>' \
-F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/friends"}]'
https://graph.facebook.com/me
Omitting the appsecret_proof field might help but in certain regions, FB API demands for it and this is how you need to provide it