Browser doesn't send ASP.NET_SessionId cookie after OAuth2 auth server redirects to redirect_uri

Programming
, , , ,
1

I’m having difficulty using OAuth2 and Microsoft’s authorization server to get an access token with a set of permissions for a user that can be used to retrieve information from the OneDrive app via Microsoft Graph.

I GET the Microsoft OAuth endpoint (login.microsoftonline.com/common/oauth2/v2.0/authorize) with redirect_uri of my secured ASP.NET endpoint. The response_type is code id_token and the respones_mode is form_post.

After completing the authorization process, I get redirected to my ASP.NET endpoint with id_token, code, and state. The browser however is not including the ASP.NET_SessionId cookie in the request due to its SameSite attribute being set to Lax. If I set the SameSite cookie attribute to None, the endpoint can be reached, but this is not a secure solution and only endpoints with [AllowAnonymous] attributes can be reached.

The Initiator of the last call is oauth20_authorize.srf, which is different from other websites that typically use document. I’m not sure if this is the right track.

Is there a secure workaround solution to this issue?

2

Yes, there is a secure workaround for this issue. You can update your ASP.NET endpoint to handle the redirect from the Microsoft authorization server without relying on the ASP.NET_SessionId cookie.

Instead, you can use the state parameter that is returned in the redirect URL from the authorization server. This state parameter can be used to maintain the state of the user’s session. You can store this state value securely on your server and associate it with the user’s session.

When you receive the redirect with the state parameter, you can retrieve the associated session state on your server and continue the authentication process. This way, you don’t need to rely on the ASP.NET_SessionId cookie for session management.

Make sure to validate the state parameter to ensure it hasn’t been tampered with before using it.

By implementing this workaround, you can maintain session security without relying on the SameSite attribute of the ASP.NET_SessionId cookie.