...
By extracting the serviceId from the bearer token, we can ensure that the `serviceId` is always available and accurate, enhancing the security and reliability of the API.
Istio with Keycloak service mesh general use
When integrating Istio with Keycloak for JWT-based authorization, the typical workflow involves clients obtaining a JWT (JSON Web Token) from Keycloak, which is then used to access services secured by Istio. Keycloak acts as an identity provider (IdP), issuing tokens that contain various claims about the authenticated user or client.
A JWT from Keycloak includes three parts: the header, payload, and signature. The payload carries the claims about the user or client, and it is used by Istio to make authorization decisions.
1. Header: This part of the token contains metadata about the token itself, such as the type of token and the signing algorithm used. For Keycloak, this often looks like:
{
"alg": "RS256", // or another algorithm
"typ": "JWT",
"kid": "key-id" // key identifier, optional
}
2. Payload: The payload contains the claims, which are statements about the entity (typically, the user) and additional data. Some common claims include:
A sample payload might look like:
| Code Block | ||
|---|---|---|
| ||
{
"iss": "https://keycloak.example.com/auth/realms/myrealm", #Issuer of the token, typically the Keycloak server URL.
"sub": "12345678-1234-1234-1234-1234567890ab", #Subject of the token, usually the user ID.
"aud": "myclient", #Audience for whom the token is intended. This is usually the client ID.
"clientId": "myclientID", #Custom Parameter
"exp": 1627584000,
"iat": 1627576800,
"nbf": 1627576800,
"jti": "abcd1234efgh5678ijkl9012", #JWT ID
"preferred_username": "user",
"email": "user@example.com",
"roles": ["user", "admin"]
} |
3. Signature: The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way. The signature is created using the algorithm specified in the header and a private key, and it is then appended to the header and payload.
Client ID
The client_id is a common parameter in the payload of a JWT, particularly in tokens issued as part of OAuth 2.0 or OpenID Connect flows.
https://www.keycloak.org/docs-api/latest/rest-api/index.html#ApplicationRepresentation
Getting Admin Token
curl -k -sS --request POST \
--url "http://$KEYCLOAK_HOST/auth/realms/$REALM_NAME/protocol/openid-connect/token" \
--data client_id=$CLIENT_ID \
--data username=$USERNAME \
--data password=$PASSWORD \
--data grant_type=password \
--data scope=openid
Getting Client Secret
curl -k -sS -X GET "http://$KEYCLOAK_HOST/auth/admin/realms/$REALM_NAME/clients/$CLIENT_ID/client-secret" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $ACCESS_TOKEN"
TODO and topic to follow
- Evaluate the necessity of optional fields: Determine if certain optional fields can be removed or if their use can be better documented to avoid dead data.
- Consider adopting more specific schemas for critical operations: This can improve both the documentation and the generated code quality. Leverage OpenAPI Features: Use OpenAPI's advanced features like `allOf`,
- Prepare for code adaptations: Implement patterns like Adapter/Builder/Transformer to handle translations between similar objects, facilitating easier maintenance and adaptation to specification changes.
- Regular compliance checks.
...