I am doing a desktop app with okta using for user authentication
I stick to OTP initial authentication over email/sms with code
So
POST /passwordless/start -> sends code to email/sms
and then
POST /oauth/token <- code
these work quite good.
The user will be created in the 'email' connection (after code verification) that's ok.
That means - they will't be able to login by email/password (because email/password users are in the 'Username-Password-Authentintication' connection).
I was thinking to force users to create accounts in 'Username-Password-Authentintication' connection, after OTP verification.
And do 'user linking' (that works fine), so they can log in by OTP or email/password.
But as the connections are different, there is a chance that the email will be already busy/created by some malicious user.
is there any way how to make possible both OTP and email/password authentications for users?
Related
I am looking at using the new Spring Authorization Server. I have got the samples working and seen how the test users are validated but have a question about where the user registration function should be added.
Should this be added to the authorization server or another separate service (e.g. userprofile)? If it's the latter, I assume I would have to connect the auth server to the user database.
Ideally, I would like users to click a login button, they are taken to the login page on the auth server. If they don't have an account, they create one and then they are taken back to the app with a token.
I was looking at the openid connect initiating user registration spec but don't think it has been implemented.
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 ...
I have successfully migrated to devise_token_auth (from simple_token_authentication), however for UX reasons I'd like to allow a user to sign up for their account, use their account immediately (previously done by returning a token in the signup response), and then confirm their email to unlock certain functionality. How can one achieve this flow via this gem?
The user is by default signed in after registering.
You can grab the access-token and other information from the query string of the url that you set as the confirm_success_url i.e the url to which the user gets redirected to after signup. Use that authentication token to make a request to the server for protected resources.
I have a rails application, and I authenticate users to the application using Devise.
The question is that I'm building an Android application and I want to understand how is the flow of authenticating users on the android "the easy way". I read about Basic and Digest Auth.
or the api I use Grape https://github.com/intridea/grape which has Basic and Digest middleware for authentication.
Am just wondering should I have store email/password of user on the android app?
and each request to the api should attach the email/password of the user?
Also, whats my benefits of the auth headers in the authenticated response?
I would highly recommend NOT storing the password anywhere, and storing the username is also most likely unnecessary. Instead, look into the token_authenticatable feature in Devise shown in this blog example. What I would recommend doing is when the Android app user enters his/her username & password combo, you call a custom token authentication sign_in controller with what the user entered and return the token to the app. Then you can store the token in your app without worrying that the username/password may be compromised.
This gives you the flexibility for how frequently you want to regenerate the token, or to invalidate a token arbitrarily.
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.