ASP.NET Core
A set of technologies in the .NET Framework for building web applications and XML web services.
4,815 questions
Did you try this article?
How to use OAuth2/OpenIDConnect flow as sessionless, without cookies
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(48, 65%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EZG%3C/text%3E%3C/svg%3E)
Zach Gardner
0
Reputation points
When I use the OpenIDConnect authentication flow for a .NET Core 6 app, it only supports doing so with cookies, leveraging a session to store the information. If I want to create a microservice implementation that is stateless, and does not use sessions, how can I use OpenIDConnect?
{count} votes
-
Vahid Ghafarpour 23,120 Reputation points2023-08-14T20:27:35.3533333+00:00 -
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(121.6, 59%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
AgaveJoe 1,510 Reputation points2023-08-14T20:29:11.1166667+00:00 When I use the OpenIDConnect authentication flow for a .NET Core 6 app, it only supports doing so with cookies,
Cookie authentication is found in browser based authentication/authorization. There are other OAuth/OIDC flows and clients that do not use cookies. Server to server or code typically sends a token.
If I want to create a microservice implementation that is stateless, and does not use sessions, how can I use OpenIDConnect?
OIDC is protocol. First figure out the types of clients that will access the microservices. Once the clients are known then you can pick the flows needed to support the clients.
-
Zach Gardner 0 Reputation points
2023-08-14T21:08:19.45+00:00 @Vahid Ghafarpour the ASP.NET Core 6.0 Web App Sign-in user example uses MicrosoftIdentityWebAppService, which looking at the docs leverages cookies to correlate the user to a session with the authentication/authorization information
-
Zach Gardner 0 Reputation points
2023-08-14T21:10:05.7033333+00:00 @AgaveJoe I'm familiar with OAuth flows which do not leverage cookie based sessions. But from everything I'm seeing in the docs, the .NET Core OAuth/OpenIDConnect implementation uses cookie based sessions to keep track of the authentication/authorization information received during the callback.
-
AgaveJoe 1,510 Reputation points
2023-08-14T23:16:40.5466667+00:00 Again, cookie authentication is used in browser based applications. If your application has a browser client then an authentication cookie is standard. If the application supports desktop and/or server clients, well, there are flows for these clients too. The framework supports these clients as well.
Sessionless mean the state is stored in the URL which is not recommended. Plus you'll need write code to deal with state being the URL.
What kind of clients does your application support?
-
Zach Gardner 0 Reputation points
2023-08-15T12:59:10.99+00:00 @AgaveJoe I would say, cookie based sessions are one of the many ways to keep track of authentication in browser based sessions. I wouldn't say that sessions in general are a standard, nor the only way to keep track of authentication, especially in a stateless microservice deployment.
The application needs to support web based human clients. Meaning, it goes through an OAuth flow where the user can enter their credentials with their IDP, and what the callback API gets is a JWT along with metadata like how long it's valid for. I want the ability to control where that gets stored, not in a cookie based session but actually on the user's browser.
-
AgaveJoe 1,510 Reputation points
2023-08-15T14:34:28.4966667+00:00 I would say, cookie based sessions are one of the many ways to keep track of authentication in browser based sessions.
It is true there are other state management options in ASP.NET Core applications.
Session and state management in ASP.NET Core
A cookie is the most convenient option when it comes to securing an MVC or Razor Pages application. Maybe you are you building a Blazor application?
I want the ability to control where that gets stored, not in a cookie based session but actually on the user's browser.
Authentication cookies are HTTP cookies and stored in the browser. Can you explain what "but actually on the user's browser" means?
Maybe local storage is what you're looking for.
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Lastly, you still have not explained the microservice security. Is the client a Blazor application or JavaScript? Is the client the ASP.NET Application hosted on a server? Are you passing the user's identity or server identity?
-
Zach Gardner 0 Reputation points
2023-08-15T17:05:40.6333333+00:00 @AgaveJoe all good questions :)
End user is using a React single page application. AJAX requests need to hit the API Gateway, where it does things like authentication checks, rate limiting, WAF, etc. Then if all of those checks pass, the API Gateway calls endpoints on the individual microservices, where the microservice does authorization checks on the controller methods, and can do access control validation on individual data entities themselves.
Having an OAuth flow is ideal as all of my users are going to be registered in Azure AD, and need to sign in before using the application. So I want the API Gateway to issue a 302 to login.microsoftonline.com for the tenant id/client id that corresponds to the app registration I setup for this use case. Then when Azure AD hits the sign in endpoint with the JWT, I want to be able to respond back with a page the user's browser runs that stores the JWT in session storage. The JS can then take that record in session storage, and use that as the value for the Authorize header on subsequent requests.
This setup doesn't require me to setup stateful sessions with cookies. It allows me to leverage the JWT authentication/authorization middleware to validate the JWT's lifetime, audience, issuer, etc.
But the part that I don't like about the OpenIDConnect middleware is that it forces me to go down that cookie route. I don't want this setup to be stateful, and have to worry about session affinity or externalizing my session storage. I intentionally architected the solution to not leverage sessions at all, as these microservices are intentionally stateless.
The only route I've found that I could get this kind of (honestly fairly common in a modern software factory) setup is by implementing the 302 to Azure AD (or whatever M$ is calling it these days) myself, creating the API controller method to handle the sign in redirect, responding back to the browser a HTML page that puts the JWT in session storage, then using the JWT bearer middleware as my auth_n/auth_z layer.
Perhaps I'm either too much of a luddite or a futurist, but it seems like this stateless microservice setup should be fairly banal in '23. And I get that cookie based sessions are a path of least resistance and easy to setup. But sessions are so 2000-and-late, especially in a service mesh architecture.
-
AgaveJoe 1,510 Reputation points
2023-08-15T19:58:41.4233333+00:00 I though you were building a ASP.NET Core web application. Have looked into the MSAL library for React?
-
Zach Gardner 0 Reputation points
2023-08-15T20:06:55.4733333+00:00 I'm building microservices using .NET Core Web APIs. MSAL for React would still defer to whatever OpenIDConnect's /oidc-signin page handler is using, which is cookie based sessions :(
-
AgaveJoe 1,510 Reputation points
2023-08-15T20:13:07.7566667+00:00
Sign in to comment
3 answers
Sort by: Most helpful
-
Vahid Ghafarpour 23,120 Reputation points
2023-08-14T20:27:21.5766667+00:00 -
Zach Gardner 0 Reputation points
2023-08-14T21:06:21.0233333+00:00 That would work for a Service-To-Service call, but the OAuth2 flow is for a user and that's more what I'm looking for.
-
Zach Gardner 0 Reputation points
2023-08-15T12:56:02.7333333+00:00 Yup, saw that article. It would work, for the flow of a backend service needed to authenticate. I have an end user, human, made of mostly carbon and H2O, that needs to go through the OAuth flow. And Azure AD gives back a JWT, which I don't want to immediately correlate to a cookie based session, but be able to configure where the user's browser stores that JWT.
Sign in to comment -
-
SurferOnWww 4,156 Reputation points2023-08-15T01:07:05.8233333+00:00 Can the following Duende Software document help?
Protecting an API using Client Credentials
The above document describes the token-based (not cookie-based) authentication using the OpenID Connect protocol.
-
Zach Gardner 0 Reputation points
2023-08-15T12:54:54.48+00:00 Correct, it uses token-based auth with OpenId...for a backend service. What I'm looking for is an example of an OAuth flow, meaning a human being is sitting there and logging in with their IDP, and what we get back from Azure AD is a JWT that we don't just store in the cookie based sessions.
Sign in to comment -
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 61%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
Bruce (SqlWork.com) 74,851 Reputation points2023-08-15T15:40:59.38+00:00 a persistent storage is only required if the web service needs to make an api call on the behalf of a user (get token silently). in this case the user access (and refresh) token is stored for use with subsequent requests. if your service does not need a user access token, then no session is required. the cookie has the user identification.
but a micro-service is not typically a browser web site, its an api. I would expect it to use bearer tokens rather than cookie authentication. this does not require session.
-
Zach Gardner 0 Reputation points
2023-08-15T20:05:48.3333333+00:00 Bruce, hmm, microservices are an increasingly popular option to decompose a monolithic API. So to me, I don't see it quite that clear cut, where microserivces are only called by other APIs.
-
Bruce (SqlWork.com) 74,851 Reputation points
2023-08-15T20:26:04.84+00:00 a microservice is often behind a gateway api. Nowadays it's typically expected to be a REST or gRPC service.
It would be a really uncommon usage of the term to mean a website accessed directly by browser (not javascript).
-
Zach Gardner 0 Reputation points
2023-08-15T20:36:06.5366667+00:00 Right, a stateless microservice behind an API Gateway. Where the API Gateway performs authentication, and the stateless microservices are where authorization is enforced.
The browser hits the API Gateway to become authorized, then does subsequent requests to the API Gateway that are then deferred to the downstream microservices. And the JWT Bearer token (ideally) that the JS client hit the API Gateway with is sent to the downstream microservices.
What I'm seeing on the OpenIDConnect is that the API Gateway is where the session is located. And I would have to then wire up the downstream microservices to "share" the same session as what the API Gateway has, storing the session data in some centralized and external system such as Redis or MSSQL.
I would rather have the microservices and API Gateway be stateless*, as sessions pose their own problems.
(*) If the API Gateway does need to enforce rate limiting on a per-client basis, it would be required that some correlation information is retained across requests, perhaps in a very fast in memory cache such as Redis, so that it would be able to see how many requests a particular client has made in a given time period.
Sign in to comment -