Is there any way to invalidate user sessions after successful password reset? Currently I'm trying to figure out some way to do it with our setup (IS 5.8.0). We want to achieve situation where i.e user is logged in on PC and on mobile or other PC, he resets his passwords then after that, he should be logged out of all PC and mobile devices.
IS revokes the sessions and accesstokens with the password update event.
Since your requirement is to force logout the users from your application side,
Option1:
since the accesstokens are revoked in the identity server-side, you can periodically check whether accesstoken is active and if it is not active, you can force logout the users from application side.
Option2:
Since the IS triggers session termination event when revoking the active sessions, you can write some custom event handler to listen to session termination event and write the logic to send some custom notifications to your applications.
For IS5.8.0, you can use either one of the above option.
From 5.12.0-m5 onwards, when the session termination gets triggered internally (Eg: password update, session termination by rest api, Note: IS already supports OIDC back-Chanel logout if session termination is triggered by user logout mechanism), IS will send OIDC back-channel logout notification to the OIDC applications if the applications have enabled it.
Related
Does ORY Hydra currently have a feature that verifies if a client is logged in via OpenID Connect? I notice there is an API to logout via front-channel
When a user revisits the identity provider, however, I have no way of knowing if they are currently logged in or not. They could delete their client-side HTTP cookies and then I am out of sync with Hydra. Meaning: Hydra has them as logged in, but I have them now as logged out. Also, in the event of a back-channel logout, I want to be able to query for this state.
Is there an API I am overlooking that allows me to know whether a client currently has an active OpenID Connect login via Hydra?
It appears as of right now the only thing one can do is redirect the user to the authorization endpoint since we have no way of knowing if they are authorized or not.
The following two tables that ship with Hydra seem to be the source of truth for the data I am after: hydra_oauth2_access and hydra_oauth2_authentication_session. Does it ever make sense to query those directly if there is no supported HTTP API out of the box to see if a user has an active authentication session?
Sending an authentication request via a redirect to the Provider including prompt=none addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code login_required if not.
Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.
LOGGED IN STATE
An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:
The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser
AUTHORIZATION REDIRECTS
When an OAuth UI redirects the user, it is generally unknown whether:
The user will be prompted to login
The user will be signed in silently (eg the user could have signed in to another app)
For a Web UI it is possible to send an authorization redirect on a hidden iframe with a prompt=none parameter. If the user needs to sign in a login_required error code will be returned. See my Silent Token Renewal Page for further details.
This is not fully reliable however, and has some browser issues in 2020. Also it may be unsuitable if you are using a different type of client.
FEDERATED LOGINS
In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.
There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.
IS THERE A USABILITY PROBLEM?
If so, post back and we can discuss further ...
We have 3 applications: admin site running IdentityServer, SPA, webapi with rest services.
On the first one (with IdentityServer) we have some aditional admin ui. A requirement exists that the connected user can seamlessly go from our SPA application to this admin ui without authentication. So, from one web application to the other by redirection.
The question is how to keep both 'sessions' in sync so none expires while at least one is in use?
Example of the problem:
Settings of the apps:
spa_web.com - our spa application -> gets the access token valid for 1 hour and a refresh token.
authorityWithIdServer.com - our id provider site -> has a cookie mantaining session set to 1 hour expiry.
Steps:
1. First we go to spaWeb.com.
2. User needs to be authenticated, so is redirected to authorityWithIdServer.com where he fills out the login form.
3. Using authorization code flow, we are redirected back to spaWeb.com and finnaly get the access token and refresh token which are locally stored.
4. We are using only the spa application for a few hours. Our access token is periodically renewed with the refresh token.
5. Now we decide to go to the admin ui present on the authorityWithIdServer.com.
6. We get the login form again to sign in to that application.
Is it anyhow possible to slide the cookie of authorityWithIdServer.com while we are using spaWeb.com in order not to be forced to login again.
You should not be using refresh tokens in client side apps. Change to authorization code and use the silent (prompt=none in an iframe) way of renewing the token. oidc-client-js implements this out of the box along with session monitoring.
If you do the above then since the renewal request happens in the context of the browser via the authorize endpoint and thus authentication with the IDP is done via cookie then any sliding logic will kick in automatically.
Also note that identityserver4 lets you control how frequently a client must interactively authenticate via the authorize endpoint max_age parameter and the UserSsoLifetime client setting.
I have an app which requires users to log in. Logging in is handled via a POST request to my back-end REST API, which generates a new access token if the login details are correct and returns it to the app (which is then saved in the keychain). My question is, how do I handle cases when a user logs in from multiple devices at once? The device who logged in first will not realize that their access token has expired, but will continue to try to send requests which will be denied (because the access token no longer matches the one stored in the database). I have thought about checking that the access token matches the database token in viewDidLoad in my AppDelegate, but this would only work when the app is first loaded. Is there best practice already established for this sort of thing? If so what is it?
The best solution I have thought of so far is to just re-issue the same access token each time the user logs in, but this seems insecure to me. Is this a safe way to handle it?
It's a good practice to issue a new token on each sign-in. Tokens are meant to be expendable, and differentiating between user sessions on different devices and browsers is useful (see Facebook's session management for an example).
There are two possible ways to handle the double login scenario:
Maintain multiple active tokens for each user in your database and invalidate each on sign-out
Allow only one token per user, invalidating the existing token on sign-in
The choice depends on the nature of your application. In the second instance, the first client won't know that its session is invalid until the app makes a network call. At that time, your server should return a custom error to indicate that the token has expired. The app should then alert the user and return them to the sign-in screen.
Is it possible to authenticate a user using Google OAuth without forcing the user to choose allow / deny (ie. is it possible to "auto-authenticate") when I already have the user's refresh token, but their session with the application is no longer active?
Such as:
The user is using a different computer
The user is using a different browser on the same computer
The user's computer is re-imaged on every restart / cookies cleared on restart
Our session cookie expired
Note that I've set approval_prompt=force since I need the refresh token. Thanks.
Depends what you want to do... no user interaction is required to use a refresh token to get a new refresh token for whatever the scopes were. But a refresh token can’t be used to verify user presence, its whole point is to do this stuff when the user is absent.
If what you need to do is test that the user is present, you have to go through some sort of authentication interaction, with one exception. If you know the email address and do an OpenID Connect login with a scope like "openid email" and you send the email that you know about along using the login_hint parameter, then if that email user is present and signed in, your operation will succeed with no interaction required. Some useful details are at https://developers.google.com/accounts/docs/OAuth2WebServer
I am implementing a login process for my app, for that I have created a login screen and a sign-in button. So if the user is not signed in I have a register button which opens another form so that the user can register himself, after which I have provided a Done button which when clicked will send the information to the server and sends an authentication code to the users email address that the user entered in the iPhone app. Then the user will be registered.
So now I want to know what are the best ways to send the username and password to the server once the user is logged in? How is it possible to save the user name and password so that when at later time when the user opens an application he should not be allowed to login again?
The easiest way for secure transmission of the credentials is to use Https. On successful authentication you'll receive a "cookie" that you can store locally in the user defaults. That cookie will typically expire. So, on subsequent logins, you can check that the cookie hasn't expired, and continue to use it for your server communication.
If the cookie does expire, then you prompt the user to login again, thereby receiving a new cookie from the server.
Storing any user credentials on the device is a big no no. The only way you can do it is to store a hash of the password. You would still need to check a hash of the entered password with the stored hash to check they are equal. It doesn't really give you anything other than a local - no server required - authentication.
Of course don't forget that without having to login again, the app will be vulnerable. Someone else could use the app and the owner's server session would still be active.