Step 1 | User sign in (to Token Provider). To access a protected data or a service residing on Integration Server, client sends a request for a JWT bearer token using his or her credentials to a third-party token provider. | |
Step 2 | Obtain JWT. After authentication, the token provider creates a JWT and returns it to the client. | |
Step 3 | User uses the JWT. Every time the client sends a request to access a resource or service in Integration Server, client sends a copy of this to token along with the request to Integration Server. Client sends the JWT in the authorization header using the bearer scheme to authenticate itself. | |
Step 4 | Integration Server validates the JWT. Based on the issuer to certificate mapping defined in Integration Server Administrator, Integration Server identifies the certificate alias and uses the corresponding public key to verify the signature. If signature verification fails, then the request is rejected. Note:Integration Server does support unsigned JWTs (JWTs without a signature). After the signature is verified, Integration Server verifies the claims contained in the JWT payload. | |
For the claim name... | Integration Server verifies if... | |
iss | The issuer id matches with the trusted issuer list defined in Integration Server. | |
sub | The user is mapped to an Integration Server. | |
aud | The audience value matches with the audience defined in the Global Claim Settings in Integration Server. This can be a list or a single value. If it is a list, then the defined Audience in Integration Server should be one of the value in this list. | |
exp | The expiration time mentioned in the claim is greater than current time. | |
nbf | The time mentioned in the claim is right for processing the request. | |
If verification of any of above claim fails, then Integration Server rejects the request. | ||
Step 5 | Integration Server responds to the user. After validation, Integration Server responds to the client with the requested data or with an appropriate error message. |