I am new to Spring Boot and OpenID Connect. I am following this article and successfully authenticated the user and created the session in my Spring boot application. Now I am stuck on implementing these two requirements:
How do I use refresh token grant type to renew the access-token? Do I need to write one more filter to check every time if token is expired and renew the same?
In that case, how do I replace existing UsernamePasswordAuthenticationToken in session? Could you provide me some sample code?
Ho do I handle SSO? I am going to have multiple application on different platform, the requirement is to logout the user from all applications if he logs out from any application. In angular or any front end application, it can be done by following the OIDC specifications of session management. But my application is Spring boot, how do I achieve this?
Related
I am trying to figure out how to perform single sign on with OAUTH2 on two different applications. Currently according to my understanding I can use the Authentication Provider in order to authenticate my clients. The procedure is the following:
The client is redirected to the Authentication Provider
Then the client is loggedin and has the code
The client provides the code to my application
The server uses the code in order to retrieve the access token.
Using the access token my server uses the remote API to retrieve information
Now I have a second application in a different backend (PHP) that I want to inform that the user is already loged in via the OAUTH. My naive solution is to provide the access token of the first application to the second application in order to perform the authentication. However, I understand that I am not allowed to share the access tokens between apps.
Every backend service should validate the access token via introspection. The only introspection guarantees that the token is valid, not expired or revoked.
So you have to pass the access token to the Backend service. To secure that you can use HTTPS API.
You are correct regarding not sharing the access token. The Authentication Provider should also allow creating an ID token. You would configure your second application with the authentication provider and get a client id. Both the client id and ID token are required to sign in the second app which will generate it's access token.
What grant type are you using?
Both apps need to redirect the user:
In the first app the user will authenticate and the app will get an access token scoped to that app.
In the second app the user will be automatically signed in without needing to reauthenticate. The app will then get a separate access token, generally with different privileges to that of the first app.
This is standard SSO behaviour and it is best to accept it. Usability is pretty good. Trying to share tokens is not advised unless you have advanced requirements.
I'm new to security domain, and recently I have learned about Oauth2.0/OpenID connect and JWT tokens. I have an existing REST based web application where I need to implement security.
Server
Application A: Spring boot back-end application sever, with some RestEndpoints exposed connected with Mysql database.
Front End
Application B: Spring boot Web Applicaiton which have some JSP pages for login and some other template features(Also connected with same Mysql database used by back-end server).
Application C: Inside application B we have an Iframe in which Angular app is running, angular app calls the back-end server and show data.
Also in future we want to use SSO for our application as well.
Current Security
At the moment we don't have any security on back-end server (i.e We can simply call RestEnd points without any authentication), Application B has basic login security implemented via spring security. User logins on application B and then he/she can use application C (Angular) as well. User session is managed at Application B, when session expires users forced to logout.
Oauth2 Authorization
What we are trying to acheive is make the server (Application A) as Oauth2Resource server and Oauth2Authorization server. Application B (JSP front end) remove database connection from it as well as the login controller, application B will call oauth2 server for authorizing user with "password" flow, when application B will receive access_token and refresh_token it will then somehow pass it to Iframe (angular app) to store these tokens inside cookie and on every subsequent request to server angular will add access token to it.
I've read articles about that Oauth2.0 have deprecated the use of "Implicit Flow", and they prefer to use the "Authorization Code Flow". I am having a very hard time to understand how this flow can be used for single page applications(SPA like angular). Also where to store the access_token and refresh_token if I use the implcit flow? I'm aware that storing both tokens in cookies is not a good practice.
Also how to manage user session now? what I have gathered so far is that, on requesting resource server with Bearer access token, when we get unauthorized response, we'll then request for new access token with help of refresh token, but in case when refresh_token is also expired I will force user to login screen. Is this right approach?
Sorry for the long context, any help will be highly appreciated. Thanks
A couple of recommendations:
Use a low cost cloud Authorization Server, eg Azure or AWS
Focus on building great UIs and APIs, which is not easy
In terms of flows, use the Authorization Code Flow (PKCE) and the OIDC Client library to manage SPA security.
A good starting point might be my First Tutorial to understand how to get integrated. Generally:
SPAs use short lived access tokens and should store them in memory
SPAs traditionally do not use refresh tokens directly
Feel free to post back follow up questions and I can point you to additional resources. You should aim to avoid running the SPA in an iframe by the way - see my other answer.
Lets say i have 5 applications and I have a common auth server.
My applications redirect the page to auth server for the first time, gets back a JWT token and then allows the user to use the application further.
Now the user is ready to use the application, but the application's backend has no clue on whether the token is still valid or expired. So Am I supposed to make a validation call to my auth server every time an API in my application is called before processing the request? Is it not adding additional overhead (multiple hops) and impacts the response time of the application?
Is it possible for the application to check the validity of the token by itself without making a network call to the auth server? What are the best practices an application developer should follow while using an auth server for SSO?
Is it possible for the application to check the validity of the token by itself without making a network call to the auth server?
Expiration: Include en exp claim into the token with the expiration date. Any client can decode the token and check the date
Signature: The client can verify the signature of the token to check if it comes from the expected server and trust the contained data. Then you would need to use an assymmetric keypair (e.g RSA)
What are the best practices an application developer should follow while using an auth server for SSO?
This question is opinion-based and is off-topic in StackOverflow. Could you be more specific about your doubts or include a programming issue?
Is SSO an overhead?
No, your application is clear example of why a SSO system is needed:
SSO: 5 apps ->1 user login
Without SSO: 5 apps -> 5 user logins
I am exploring keycloak for my project SSO solution, and I am trying the open-connect on this blog https://developers.redhat.com/blog/2017/05/25/easily-secure-your-spring-boot-applications-with-keycloak/
And I would like to as one question about Single Sign Out, I would like to know what’s the principle behind. Tried to search online document but I didn’t find any clue .For a while, I was thinking there is no elegant solution for Single Sign Out in oauth2 world.
This is the way Keycloak implements it (yes, this is not part of OAuth):
when you use Keycloak to create a server side session in your application using the Java Client, Keycloak will trigger a logout of the session once the logout at Keycloak is triggered. You'll need to set up an Admin URL for your application in Keycloak. This is called "backchannel logout" in the documentation.
When you use Keycloak in a HTML5 client, Keycloak will create a hidden IFRAME that will check that the Keycloak-Cookie is still present. If it is not, the HTML5 application knows that you have been logged out.
OpenID Connect Back-Channel Logout seems to be the way to go nowadays. It works by exposing a special end-point in your application (backchannel_logout_uri), which will be invoked by the OpenID Provider when the user logs out from SSO. Through this endpoint, the Provider gives you a signed Logout Token, to notify your application that the user's session should be terminated.
Because a user may be logged in from multiple devices, browsers, etc., the OpenID Provider can also include a Session ID (sid claim) as part of the Logout token. You can compare it with the sid that you would have received in the ID Token during login, to decide which session to terminate.
The standard back-channel logout was implemented in Keycloak 12.0, which shipped in December 2020. Earlier versions only implemented an alternative, proprietary mechanism.
We have all the user data in our local mysql database. We are moving our services to cloud and I need to use cloudfoundry UAA to authenticate by calling a login microservice endpoint on our network instead of doing uaac add user for all the users in db.
I am new to this, it would help me if you can explain the steps to do it.
Thanks in advance
I assume (based on the SAML tags on your question) that you are thinking of doing this with SAML. If this is your first time doing SAML then there is a bit of learning curve. If so you may find it easier to just creating a custom Login app.
SAML
You would setup an Identity Provider and the IdP would authenticate users against either mysql or your login microservice. simplesamlphp can be used for this purpose. A user would authenticate to the IDP, the IdP generates a SAML assertion (e.g a signed xml doc with information about the user) that gets sent to the Service Provider (UAA). The service provider then looks at the assertion to determine who the user is. UAA supports SAML logins. It has been a while since I've set it up that way, but I recall you run a separate 'login' war from the rest of UAA, and the login war uses APIs to talk to UAA. You also need to configure the SAML trust relationship between ssp and the UAA login war. This isn't hard to do if you are familiar with SAML. If you aren't then it can be difficult to get all the pieces right.
Custom Login App
I think an easier approach is to just build your own login app that calls your authentication service and the UAA apis. UAA provides a sample app and documentation