We are currently trying to work with some internal application developers to get them configured to use OAuth2.0 for their app. We are running into some issues where they are able to get their users logged in, but their idle session times are not being updated and they are having issues logging the users out successfully. We’ve confirmed that they are able to send the request to the access_token/revoke endpoint, but ForgeRock support specified that the app code should be able to send a request to the logout URL (‘https:///am/json/realms/root/realms/alpha/sessions/?_action=logout’) to end the session and revoke all the tokens at the same time. From what we saw trying to use this, we were getting an authorization error, and that logout endpoint seems to only accept calls using an AM admin’s token.
Part of their issue is that that requires including the session cookie name and session ID. We currently have the application configured for server-side sessions which seems to be preventing them from collecting that information. We believe CORS may be a solution for that, but they are not sure what the C# code needs to be since all of the ForgeRock documentation is cURL specific.
These are the endpoints they are currently utilizing in their code:
“Instance”: [tenant URL]/am/oauth2/alpha/,
“AuthorizationEndpoint”: [tenant URL]/am/oauth2/alpha/authorize,
“TokenEndPoint”: [tenant URL]/am/oauth2/alpha/access_token,
“UserEndPoint”: [tenant URL]/am/oauth2/alpha/userinfo,
“Scope”: “write”,
“RevokeEndPoint”: [tenant URL]/am/oauth2/realms/root/realms/alpha/token/revoke
We’re trying to find out if anyone else has configured .NET C# code and what the correct way to configure these requests on the application side should be.
Thank you for submitting this discussion point.
It is a common misunderstanding that “a valid authentication session” and “Oauth2 access token” is one of the same. But they are not. Moreover, unless you have explicitly provided correlation data, there is no relationship between OAuth2 tokens and SSOTokenIds.
The reason for this is that SSOToken implies a valid Auth-N session with AM.
The OAuth2 token implies an Auth-Z authorization for a client. There is no need for the Resource Owner to have a valid Auth-N session to use an OAuth-2 Access token with their client.
Your need to “End all sessions” does not extend to OAuth2 tokens. Do note that the endpoint “./sessions?_action=logout” is purposely not included as a valid OAuth2 endpoint.
Incidentally, this is a common misunderstanding. And one of the motivating factors to using OIDC.
You can effectively share data a number of ways. Another approach is the Security Token Service: REST STS :: AM 7.5.0
So, if I may suggest, though this tight integration in the code of the app may seem like an appropriate approach (and it is if done correctly) The common modern application integration architecture is to capitalize on the value of “gateways”. IG is such an example. The integration of IG would drastically simplify your needs for appropriate, in scope data exchange between the provider and the consumer app AND act as a PEP to your app.
Cheers.
Hello Guy,
I may have not provided enough information. The application owners do not want to move to OIDC, and we are using Identity Cloud purely for the SSO Auth-N piece. This was also a move from an Azure App registration with the understanding that the existing code was Microsoft specific and that there would need to be significant changes. In addition, while we are using Identity Cloud for passthrough Auth-N only, we are not syncing passwords into Identity Cloud for security reasons.
Our current Identity Cloud tenant is using the CTS (Core Token Service) by default because we have the application configured for Server side sessions. AM stores all of the information regarding the Access and Refresh tokens in the CTS with a specific session ID (also called the Token ID) that is returned to the client in a cookie when the user authenticates. This should allow for a more secure transaction between the IDP and SP since we can configure CORS to ensure that only the specified app URL(s) can send requests to AM to request the contents of that Token ID in the cookie.
Utilizing the CTS also should enable us to manage user sessions from the AM console in a centralized place if we need to terminate access on short notice. Since the CTS correlates the user session to the tokens, ending the session should revoke all of a user’s tokens. If “ending the sessions” does not extend to OAuth2 tokens, it seems like that would not provide a secure way to manage an actively authenticated user on the fly if access needs to quickly be shut off. Also, AM managing the sessions allows for the session idle time to expire the user’s tokens automatically if they are inactive for too long. This ties back to the Access and Refresh tokens being correlated to the Token ID in the CTS as AM needs a way to validate that the user still has a valid session before sending back a new access token for the user when the refresh token is used.
An example of the desired behavior would be similar to how Microsoft Entra works. A user can be logged into the IDP in order to access applications configured to use OAuth2.0. When a user goes to log in, a check is done to see if they have an active session and are logged into the IDP. If they are already logged in, they could simply be prompted for MFA to validate their identity. Otherwise, they would have to fully log in including MFA. When a user is ready to log out, SLO (Single-Logout) can be configured to fully log them out of the IDP and end all of their sessions across the applications they are logged into, or the logout request should be able to specifically end the user’s login with the application so that they are required to re-authenticate next time they navigate back to the page.
The expectation here is that there is an endpoint that successfully authenticates the user against Active Directory via Passthrough Auth-N in ForgeRock, an endpoint that the application talks to in order to refresh the access token as needed and to ping ForgeRock to keep the session alive, and an endpoint to fully end the user’s session and revoke all of their tokens when they click the Logout button inside the application.
We are meandering/merging a number of terms and processes of independent services, here.
And I wonder if the complete configuration of AM is being employed properly. (As this is not Entra and does not behave the same).
Would you please reach out to me at guy.pensa@forgerock.com with a business email?
Hi vdl,
Based on what I was reading regarding the /endSession endpoint, am I understanding correctly that it’s OIDC specific and would require the application to be coded for OIDC instead of just OAuth2.0?
Good morning,
As per my earlier post. Authenticated sessions do not include any reference to OAuth2 Access tokens. OAuth2 access tokens have no reference to the Authenticated session. OIDC tokens will include a reference to the Authenticated session.
The endSession endpoint is strictly used for Authenticated sessions. It is not a valid OAuth2 endpoint.
Therefore, what is the requirement? Oauth2 client access to a resource server OR An Authenticated user using a Relying party access to a Resource? I interpret your responses as it is the latter.
Additionally, please see: /oauth2/connect/endSession :: AM 7.5.0
DO NOTE, this is an OIDC endpoint!