I have an angular app with .Net core backend application. I am, looking to implement SSO with OKTA using OpenId connect or SAML.
I have created a Web application in OKTA for the backend services and I was able to get access token back
Same thing I have created SPA and I was able to authenticate the user from the angular app.
I am trying to figure how to connect this together under one application that uses SSO.
I want the user tn be able to authenticate once he/she launches the web interface or the UI and also I want the user to be able to authenticate if he/she tries to call in the backend APIs directly (Swagger/Postman)
What will be the correct architecture here? do I create SPA application or a web application in OKTA? who should initiate the login? the Angular code or the .Net Code?
should I have the angular code authenticates and get the access token then use the same token to authenticate through the backend services?
Should I have the authentication happen in the backend only and have the UI call a service in the backend that does the authentication?
Do I need 2 applications created in OKTA one for the angular app and one for the .Net core app?
I think it all depends on how you want to deploy your application. Do you want to have it as two separate applications or one? If you want it as two, you should be able to create a SPA application on Okta and do the authentication on your frontend. If you’re OK with combining them into one, then you could create a Web application on Okta and bundle your Angular application inside of your .NET application. If you do all the authentication on the server (in .NET), it’ll be more secure because your access tokens will be stored on the server, rather than in local storage. Both solutions will work well though!
Thank You.
The angular app will be running on a separate instance than the .Net app but at the same time there is going to be some other processes that will also invoke some of the APIs on the .net app other than the angular client so I will want to secure the APIs end points as well and have only authenticated users be able to invoke the APIs from the browser or postman or any other tool.
I was thinking about having one web application in OKTA and make the authentication happens at the back end only. Create a .Net service in the backend that does the authentication and have the angular app call it rather than have the angular app authenticate directly with OKTA. That way I can secure both the app and the APIs. Not sure if that is a better approach?
If you package your apps together on the same server/port, the approach you’re trying to do will work. If you want to serve them on separate ports/domains, you’ll need to do authentication in the client and pass an access token to the server (which should be configured to validate them). I’m not a .NET expert, so I can’t help on the backend, but I’ve done this with Java and it works well.
@mraible, you mention that for Web application with SAML, access tokens will be stored on the server. What happens if there is a cluster of servers in the middleware, all server instances will have to synchronize user access tokens/sessions? How does the middleware server know for sure that the user calling the REST API is the user that pretends to be? Does the client still have some kind of hardened token like a JWS or JWE?
If you doing SAML, this is no access tokens. Access tokens only apply to OAuth. For Spring apps, you can replace the session with Spring Session, which can distribute your session via Redis, a database, or Hazelcast.
The middleware server knows who the user is via good ol’ fashioned cookies is most cases. IMO, there’s no reason to use JWTs as session tokens just so you can be stateless. This blog post has a good explanation of why.
Thank you for the quick reply @mraible
We are not using JWT as session tokens. We only use JWT for auth purposes (for the SP to make sure that the REST API caller is indeed who he pretends to be). Our middleware purposefully does not keep any kind of state hence no need for a session identifier and we would like to very much keep it that way. I find it heavy handed to have to introduce Redis or Hazelcast just for the purpose of authentication.
I am curious, what prevents an authenticated user to tamper with the ol’ fashioned cookie and pretend to be a different user in the system?
Hi, I want to use combination of Okta + React + Springboot where redirection url will be kept at Spring. Is it possible ? If yes, how come React will come to know about access token ?
Yes, this is possible. It’s how we do things in JHipster (https://www.jhipster.tech). With JHipster, the React client doesn’t store an access token. Since the front end runs on the same port as the backend, good old cookies keep the session alive.
Yes. But I’m not certain how to do it. It’s something we’re trying to figure out with the Spring Security team in a JHipster microservices context now.
I’m sure it is. JHipster just generates Spring Boot + Spring Security code. You might want to ask your question on Stack Overflow and tag with with “spring security” so you can get some help from that team.
Hi
I am doing the same as you. How did you end up architecting your project?
My intention is to use javascript SPA on the front end for all my content and have it on a dedicated server. Authentication via Okta SPA using PKCE flow.
The SPA calls the resource server using Okta Web which has a secret key but no code challenge and verifier. How do I come around this?