5634a7f390
Why: Many services in La Suite rely on Agent Connect to authenticate their users. Delegating authentication to Agent Connect is highly beneficial. With a central party (Agent Connect) handling user authentication, our services can seamlessly communicate with each other. Our backend must be able to receive and verify access tokens issued by Agent Connect. Additionally, it should ensure that the resource owner has granted permission for our data to the service provider transmitting the access token. How: Our backend needs to verify access tokens by introspecting them. This involves requesting the Authorization Server to validate the access token received in the authentication header. The Authorization Server validates the token's integrity, provides authentication and authorization information about the user currently logged into the service provider requesting data from the resource server. The data returned by the Authorization Server to the resource server is encrypted and signed. To encrypt the introspection token, the Authorization Server retrieves the resource server's public key from the new ‘/jwks’ endpoint. Encryption parameters, such as algorithm and encoding, are configured on the resource server. Ensure that these parameters match between the Authorization Server and the resource server. The resource server verifies the token signature using the Authorization Server's public key, exposed through its `/jwks` endpoint. Make sure the signature algorithms match between both servers. Finally, introspection token claims are verified to adhere to good practices for handling JWTs, including checks on issuer, audience, and expiration time. The introspection token contains a subject (`sub`). The resource server uses this subject to retrieve the requested database user, compatible with both pairwise and public subjects. Important: Agent Connect does not follow RFC 7662 but uses a draft RFC that adds security (signing/encryption) to the initial specification. Refer to the "References" section for more information. References: The initial RFC describing token introspection is RFC 7662 "OAuth 2.0 Token Introspection". However, this RFC specifies that the introspection response is a plain JSON object. In eGovernment applications, our resource server requires stronger assurance that the Authorization Server issued the token introspection response. France Connect's team implemented a stronger version of the spec, returning a signed and encrypted token introspection response. This version is still a draft, available under: "draft-ietf-oauth-jwt-introspection-response".