We need to implement an single sign on and single sign out solution for multiple applications (not in same domain and different permissions per application) having one authorization server.
Scenario 1:
If we setup one client_id: "global" with scopes: "app1,app2,app3" on auth server user is authenticated in ALL apps and user has one cookie for auth server and one cookie for each app he opens.
Problem here is that a user that has access to app1 and app2 and NOT on app3 is getting authenticated for all apps from auth server. So authorization should take place on application level.
Single sign out looks simple. Lets assume that user logout from app1, so he gets redirected to auth server and auth cookie is deleted. After he gets back to app1.domain/logout and app1 cookie is deleted as well. Authentication server is responsible to POST requests to app2.domain/logout and app3.domain/logout to delete all other cookies as well.
Scenario 2:
Each application has it's own client_id, for
For example:client_id:"app1" with scopes:"user"
client_id:"app2" with scopes:"user,public_repo"
client_id:"app3" with scopes:"admin"
When user login through app1, code-token exchange take place with auth server by using as client_id: "app1". Two cookies are now created one on auth server and another one for app1. When user now navigates to app2, another request take place by using client_id: "app2" and auth server is not able to authenticate user to app2 now. How is this feasible??
This setup does not look like and sso but looks more abstract than Scenario 1.
Any ideas/suggestions would be appreciated.
Thank you
Related
(Background: I am trying to use my website hosted on wix as a simple identity provider so my members can access a separate sveltekit app I am creating--without logging in again--on a separate server because I do not think I can create the app on the wix platform. Basically I just need the user id, but I would like to also ensure they are in fact authenticated on my Wix hosted site before granting access).
In multiple pages explaining single sign on, it is explained that when my browser requests a protected resource from a web server, the server can (if it is configured to do so) verify my identity via a separate identity provider. This is done via a redirect to the identify provider. If I am not authenticated by the identify provider, I am asked to authenticate (by entering username and password, or whatever).
Once I am authenticated (by logging in or by verifying the presence of a valid session id on the identify provider's server from a prior login), the identify provider then "redirects with token" or a "token can be passed to the original domain by a redirect" according to these web sites I have encountered.
But what does it mean to "redirect with token"? This conflicts with other reading I have done which points out that redirects cannot have authentication or other headers or data associated with them.
How does it come to pass that (1) the web server I made my original request from gets my token from the identify provider while at the same time (2) returning my requested resource to my browser instead of back to the identity provider's server?
"Redirect with token" is a common method used in single sign-on (SSO) systems to authenticate users. In this method, when a user tries to access a protected resource on a server, the server redirects the user's browser to the SSO login page, along with a token that identifies the resource being accessed and the server that is requesting authentication.
The user then enters their login credentials on the SSO login page. If the credentials are correct, the SSO system authenticates the user and sends them back to the original server, along with a token that indicates that the user has been authenticated. The server checks the token to confirm that the user has been authenticated, and if the token is valid, the user is granted access to the protected resource.
Redirecting with a token is a secure and efficient way to authenticate users across multiple servers, as it allows the servers to rely on the SSO system to authenticate users and eliminates the need for each server to store and manage its own set of login credentials.
I want to use Keycloak as an identity provider in our company.
I have defined one Realm with three clients (I have three applications and I have defined a client for each application)
I want to separate the process of login and logout for each application. For example when I login into app1 and app2 and app3, and then logout from app1, the app2 and app3 remain logged in.
In StackOverflow I found some solution to separate the login process for each application as follow:
1. in admin console, go to Authentication
2. make a copy of Browser flow
3. in this new flow, disable or delete Cookie
4. go to Clients -> (your client) -> Authentication Flow Overrides, change Browser Flow to your new flow, click Save."
How to force login per client with keycloak (¿best practice?)
But this solution is not working for making the logout process independent for each application(which means I want to disable the SSO feature in Keycloak). Is there any way to make it possible?
I would enable Direct Access Grants on the client level only (Standard Flow will be disabled), so applications will have to use direct grant flow. No IdP sessions in the user browser will be created in this case, so no SSO will be used.
We have single sign on implemented in our web product(app1) using SAML 2.0 - our product is the service provider. Now one of our clients is asking for a link in app1 which will take the user to their web app(app2) and they are expecting the user to single sign on into their application. I am assuming that their app(app2) will be using the same IDP as app1 is using.
Based on my understanding I think a link to their AssertionConsumer of app2 should do the work. When the link to the app2 is clicked app2's AssertionConsumer will be able to process the claims from app1. Will appreciate if someone will chime in and let me know if I am missing something.
You should not link to the Assertion consumer URL. You link to the relevant page in app2. App2 will detect that the user is not authenticated and send it to IDP for authentication. The IDP will detect that the user is already authenticated and return the user to the page it was originally sent to.
Does app2 do passive auth when users arrive? If so, you should just link to any page in app2 and let it take care of asking the IdP about the user's login status, rather than trying to tell it.
If app2 doesn't automatically check with the IdP, then you should probably link to a page in app2 that requires auth, so that it will.
In general, the whole point of the IdP is that it's the thing that the SPs trust to tell them whether (and how) a user is authenticated, so you shouldn't try to build an additional system of trust between the SPs. (It's fine if they hint to each other that the current user is logged in or even someone in particular, but they should check with the IdP before believing it.)
I have been reading a lot on Single Sign on and OpenId
I have checked the documentation for OpenId and Single Sign On on the below Link
Single Sign On
http://rashidi.zin.my/geek-talks/2009/06/30/php-mysql-curl-single-sign-on-with-multiple-domains.html
http://www.opengroup.org/security/sso/sso_intro.htm
http://www.authenticationworld.com/Single-Sign-On-Authentication/
http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/
https://wiki.queensu.ca/display/itsd/Single+Sign-On
https://github.com/jasny/sso#readme
https://lw.microstrategy.com/msdz/MSDL/940/docs/mergedProjects/websdk/topics/sso/SSO_Single_Sign-on.htm
OpenId
http://openidexplained.com/
http://openid.net/pres/protocolflow-1.1.png -- Flow Diagram
http://wiki.openid.net/w/page/12995226/Run%20your%20own%20identity%20server
Simple concept what i understood on Single Sign on can be explained as below
User hits domain1.com.
domain1.com sees there's no session cookie.
domain1.com redirects to sso.com
sso.com presents login page, and take credentials
sso.com sets session cookie for the user
sso.com then redirects back to domain1 to a special url (like domain1.com/ssologin)
the ssologin URL contains a parameter that is basically "signed" by the sso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key.
domain1.com takes the encrypted token, decrypts it, uses the new login id to log in the user.
domain1 sets the session cookie for the user.
Now, the next case.
User hits domain2.com, which follows domain1 and redirects to sso.com
sso.com already has a cookie for the user, so does not present the login page
sso.com redirects back to domain2.com with the encrypted information
domain2.com logs in the user.
OpenId Concept what I got can be explained as
OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.
An OpenID is a way of identifying yourself no matter which web site you visit.
Now My problem is even after reading a lot of documentation, am not sure will i be able to achieve single sign on using openID and this is very important for me to know before i start my code.
Is there any way where i can upload my database to OpenId for Authentication, So my users do not need to go through all the drill again.
I will really appreciate if anyone has implemented this earlier or has any reference for me to make this clear
Yes, OpenID will give you single signon across web applications that may live in different domains. Note that OpenID 2.0 (which is the subject of the links that you point to) was deprecated and followed up by OpenID Connect, see: http://openid.net/specs/openid-connect-core-1_0.html#Introduction
There are a number of product and libraries that you can use to build on:
http://openid.net/developers/libraries/
We have a regular web application with cookie based auth and now we want to split frontend and backend (api) in order to have third-party public API. So our backend will be on one domain and frontend on another one.
For authorization we would like to switch for OAuth 2 with JWT. In this case our frontend app will have to use access_token instead of cookie session and it brings a big old question:
How To Remain Logged In - The Infamous "Remember Me" Checkbox (part II from Form based authentication for websites)
From OAuth2 point of view our frontend application going to use something between Resource Owner Password Credentials Grant and Implicit Grant. It is closer to Password Credentials Grant since we still going to use usual login form and won't redirect user to another domain in order to sign in. At the same time it is closer to Implicit Grant since it's all going to be browser-only & JavaScript based when access_token will be saved in browser.
The RFC says the authorization server MUST NOT issue a refresh token if you use Implicit Grant and my question is if it's still valid in this use case when you don't really use a 3-d party OAuth but your own api? Instinctively I feel that having refresh_token in browser is a security hole and would like to confirm it with you guys, but that refresh_token seems to be the only way to have persistent login working the same way as we had with cookies.
**UPD** after #FlorentMorselli comment:
The OpenID specs still do not answer my question if I can use refresh_token with browser only application
Google says they provide refresh_token only for access_type=offline
OpenID Connect Core says you cannot use Refresh Token with Implicit Flow
OpenID Connect Core says nothing about using refresh_token with Hybrid Flow
There's only one place where it says something promising about refresh_token with Hybrid Flow, but nothing precise
UPD2 thanks to #reallifelolcat
It looks like OpenID Connect does not explicitly support Resource Owner Password Credentials Grant, meaning you have to redirect user to OpenID Connect server to perform login. Do you know if there is another way to authenticate with user credentials over OAuth 2.0?
I believe splitting api and frontend is getting more common these days and I'd appreciate it if you share how you solve this Persistent Login issue and if you drop it completely and force user to re-login every X weeks.
Thanks!
Access tokens and refresh tokens have nothing to do with login with OpenID Connect. These are only for authorizing access to user profile information and for perhaps authenticated service calls to your public API after the fact of login. Refer to the spec for the difference between the ID Token and the Access Token.
If you are going to use OpenID Connect for login, then from what you've wrote so far, it sounds like you need to host your own OpenID Provider (OP) since you want to avoid going to another domain to sign in:
we still going to use usual login form and won't redirect user to another domain in order to sign in.
If you want to be your own Identity Provider, then more power to you. This means that you going to have to deploy your own working instance of an OpenID Connect server, complete with authorization and token endpoints.
Now this is the part where your persistent login comes in. Your browser webapp will be a relying party to the OP server you now have. When a user tries to login to your browser app using OpenID Connect, they will need to authenticate themselves to your OP server. Going through the OIDC flow, your browser app will get an ID token containing an issuer/subject pair identifying the user.
It's up to you to determine how the user stays logged into your OP server, but as long as the user at least authorizes the browser app once:
http://openid.net/specs/openid-connect-core-1_0.html#Consent
then you can save that consent for all future requests by this browser app to login, and therefore maintain a persistent login.
You're going to have to consider how you're going to handle sessions management, but it sounds like you have some cookie thing going already so you might be able to use that (see this answer: OpenID sign in mechanism - Stay signed in ). Otherwise, you're going to end up with a situation where your browser webapp has to get a new id token all the time.
Also as Florent mentioned, there are security considerations you should consider when doing a public client thing that your browser based webapp would be. Example:
https://www.rfc-editor.org/rfc/rfc6749#section-10.16