I'm doing a Scala - Play application and I want to disconnect an user when an admin change his right. For exemple, is an user is logged and an admin upgrade his account to the admin type, I want disconnect this user.How can I do that ?
If you stored the userId in the Session you will need to add the rights of the user in the Session.
So that when the user connects, you can check his rights from the session to the ones in your database. If they don't match you can redirect the user to the login page.
just to cover all the bases since the answer here depends specifically on how your application determines if a user is logged in:
if user auth is done with a token generated by a secret that is stored on your user model and checked for validity on every request, you can generate a new secret for the user and all existing tokens will become invalid.
Related
I have a functionality in my app where the users can change their password or update their email address.
According to this document https://firebase.google.com/docs/auth/admin/manage-sessions i would assume that when the same user is logged in on another device at the same time that the refresh token should be revoced when the password changes and the user should be logged out.
It seems that this does not happen in my case. I use these two listeners to detect the changes:
addStateDidChangeListener
addIDTokenDidChangeListener
They are normally working when I login/logout via the Firebase login and logout functions but they don't get called when I change the password on another device.
Is there any way to get notified when a user change the password on another device?
Firebase Authentication uses ID tokens to maintain the authentication state on the client, and these tokens are valid for one hour. Only once the SDK needs to refresh the token (which it automatically does about 5 minutes before the token expires) is it guaranteed to detect the change, so that may take up to an hour.
If you want to force refreshing of the token before it expires, you can call reload on the User object.
Should I always check user existence in the process of authenticating? How if users deleted the account while they still have their API KEY containing user id? It can mess up some part of the system that involve the user.
I am building a SPA with a spring on the backend. I am working on signing in with Google, most of it is working already: got the id_token with the implicit flow in the frontend and I sent it and verified it on the backend.
I want to have users with roles and manage that locally (so, no adding info in the oidc provider). What are the options to go from the id_token to having an authenticated user in spring? I did not find any example doing that link manually (id_token-spring_sec_user).
I have checked several sources like the Spring Security 5 presentation at SpringOne https://www.youtube.com/watch?v=WhrOCurxFWU, several SO questions and posts on okta's and auth0's blogs but I am still missing the link.
You will have to create your own (application) specific roles.
Use these steps :
Get authenticated from Google
Access the profile section from google (username, name etc )
Use your own user table to store this info
Create admin APIs in your own system and assign your app-specific roles to the user.
When you login again you will authenticate against google login/password and roles specific to your application .
Create an account or session with the id_token
Check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record with default role from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
I'm working on a mobile application that uses Stormpath on the server side for authentication and authorization. I need to support the same user signing in on more than one device, but I want to be able to keep track of it and limit it if I want to.
My application currently uses Stormpath to sign in the user using email/password or MDN/password and upon successful login returns a JWT token to use for API access to the server.
I'm thinking of the following approach:
Keep a list of sessions in the user's account. Every time the user signs in, a new entry is added with the device_id and the JWT provided. When the user signs off, the entry is removed or marked inactive.
When a user tries to sign in on another device, if I want to restrict to only one active device, I would set the other entry to disabled and expire the JWT so the application can detect it and require login again.
If I wanted to restrict the user to a maximum of n sessions, I could just count the entries and force the user to sign off on one of the other sessions before allowing her/him to sign in on the new device
Is this a good approach? Is there a better way to do it? What are the issues with this method?
I work at Stormpath on the mobile SDKs. You can use the access / refresh token feature that we have to accomplish this.
Every time the user signs in, an access and refresh token are created. When the user signs off, the refresh token is deleted, as well as the access token.
When a user tries to sign in on another device, if you want to restrict to only one active device, you can delete all of the other access & refresh tokens.
If you wanted to restrict the user to a maximum of n sessions, I could just count the entries and force the user to delete one of the refresh tokens before allowing her/him to sign in on the new device. You would then go through the access tokens, and delete ones with a matching "rti" (refresh token ID)
Several notes about implementing this:
If you're using a Stormpath Framework integration, the default is to verify an access token locally (instead of sending it to Stormpath to validate). This is because they have a signature that can be validated by the SDK. However, to log out a user, you'll either have to set this to remote validation, or use a short access token life (and use the refresh tokens to control each "session")
Refresh tokens can't store "customData", so you'll have to maintain metadata about the refresh token in either the account's customData, or in your own database.
Alternatively, you could "create" API Keys for each user, and use that instead of sessions for each user. You can use the API Key name or description attributes to keep track of where the user signed in from / etc.
In Facebook when you change your password it has the options to automatically sign you out of any other devices logged into the same account. How does this work?
When creating the session, a session key is stored in the database alongside the cookie. This means cookies are validated server-side, with data from the database. Once logged in a user can view the session data retrieved from the database. This gives the user the opportunity to sign out of any other device because once the database entry is removed, the cookie with the same key won't validate anymore.