IUA - Canadian Implementation Guidance

The IUA - Canadian Implementation Guidance describes the recommendations for the IHE IUA (Internet User Authorization) profile.

IUA Actor Options

Note 1: The actor shall support one of the two options: Token Introspection or Signature Verification (using Authorization Server’s Public Key)

JWT Token Option

This option uses JSON Web Token encoding for access tokens issued by the Authorization Server.

JWT IUA Extension

The JWT IUA extension, described in the JWT IUA extension section of the IUA specification, are currently considered out of scope.

Token Introspection Option

The Token Introspection Option allows Resource Servers to check the origin and validity of the access token.

The Resource Server delegates the token verification to the Authorization Server by accessing the Token Introspection endpoint. The Authorization Server will perform all applicable checks against a token’s state, such as checking whether the token has expired, verifying signatures, etc.

Also, generally the token introspection allows to find out additional information such as the user and scopes that are associated with the token, however in case of JWT tokens this is not necessary, as the resource server is able to parse the token and perform these additional verifications.

Signature Verification Option

This option allows Resource Servers to check the origin and validity of the JWT access token without a network call to the Authorization Server. The Resource Server is using the Authorization Server’s public key to validate the signature of the token, and then parse the claims within the structured token itself.

The Authorization Server’s public key endpoint can be discovered using the well-known URI (see Authorization Server Metadata Option). If the Authorization Server metadata option is not supported by the Authorization Server, the public key can be obtained by other means.

Authorization Server Metadata Option

Server endpoints are available to be discovered via the well-known URI discovery mechanism. The client issues a HTTP GET request to the well-known metadata endpoint associated with Authorization Server.

An example of such a request using [RFC8414] is:

     BASE_URL/.well-known/openid-configuration

where BASE_URL includes realm (tenant) information.

Keycloak authorization server example:

• BASE_URL

               https://<keycloakserver>/realms/<realm>

• Authorization server metadata discovery endpoint

               BASE_URL/.well-known/openid-configuration

• Authorization server certificate endpoint (discoverable via well-known URI)

               BASE_URL/protocol/openid-connect/certs

Amazon Cognito authorization server example:

• BASE_URL

               https://cognito-idp.<region>.amazonaws.com/<user_pool_id>

• Authorization server metadata discovery endpoint

               BASE_URL/.well-known/openid-configuration

• Authorization server certificate endpoint (discoverable via well-known URI)

               BASE_URL/.well-known/jwks.json

Authorization Grant Types

Security Considerations

Recommendations for Authorization Server and Authorization Client that are using the Authorization Code flow:

• PKCE (Proof Key for Code Exchange) – Mechanism to protect against CSRF (Cross-site request forgery) and Code Injection
• state – Request parameter that enables additional protection against CSRF
• nonce – Request parameter that enables enforce one-time code usage and protection against replay attacks