Is there a way to implement multi factor authentication in Shiro? Can somebody give me a hint on how to implement this?
For more details:
The basic idea is, that a user needs to login just as usual, using username and password, but before being actually authenticated the user also needs to enter a one-time-token he received as an SMS.
Thank you!
I finally solved my problem on my own, but I'm of course always open to other suggestions.
I implemented my own 2 - Factor Authentication Flow:
First of all I changed the URL of the login page, to which Shiro redirects an unauthenticated user to my own login page, that leads into the authentication mechanism.
A user needs to complete two "stages" to login.
On the first stage he/she has to provide a username and password, if
these are valid, the user is redirected to the second stage of login.
Meanwhile, a one time token has been generated and sent to the user
via SMS. Also the user's authentication progress has been saved in
the session (which means I remember, that stage 1 was completed
successfully).
On stage 2 the user needs to enter the token. If the
token was
not valid or the number of attempts (5) was exceeded
expired (after 5 minutes) the number of attempts
to correctly enter the token exceeded 4 the user will be redirected
to Stage 1 and all progress will be deleted. I
if everything went fine, the user will be authenticated to Shiro
(of course without letting him/her know)
In the end the user will be redirected to the page he/she originally requested, which still allows him/her to bookmark pages. Of course Shiro's remember-me will always be deactivated.
Related
I did a lot of research on how to implement 2fa on my app.
My app will enforce every user to use 2fa (I will use OTP).
I think that in my app, (because every user will need to use 2fa, and I will use only OTP), I can have only 2 steps:
Log in the user providing username, password and OTP.
If step 1 is successful, authentication is done.
From all the sources I found, the 2fa steps are always the same:
log in the user providing username and password.
If step 1 is successful, ask the user for the OTP token.
If step 2 is successful, authentication is done.
In my head, if I have optional 2fa, or 2fa using SMS/email, then I must have the step in the middle (authenticate the user, send the SMS/email and wait for the code), but with OTP, I already have the code and I can provide it in the same login form with the username and the password.
I haven't seen this kind of 2fa with only 2 steps, am I missing something?
Both of your examples are the same.
In the First scenario, the server is waiting for the user to enter OTP and the same process follows in the second scenario.
These are distinct steps in 2FA authentication
The user sends their username and password to the server to be authenticated as usual
The server confirms the credentials are correct and asks for a second input from the user.
In this case it’s a one-time passcode (OTP)
The user provides the OTP, and the server finally authenticates the user
2FA
This is a summary of an issue I filed directly with expo (it ws closed but I have asked for it to be reopened):
This issue happens whether using AuthSession.startAsync,
AppAuth.authAsync or WebBrowser.openAuthSessionAsync on iOS in
local development and published release (expo managed). Haven't tried
on standalone build yet.
Steps to Reproduce
user presses 'sign in' button, (app calls one of the above methods to kick start authentication session with a Salesforce oauth provider)
user enters credentials successfully
app goes through oauth redirects and returns user to our app and we get our access token.
user presses 'sign out' button (app calls revoke endpoint for token, then calls server endpoint to delete any browser cookie sessions for given account reference)
app navigates to sign in screen
user presses 'sign in' again (app calls the same method from above to start the authentication session with Salesforce oauth provider again)
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Expected Behaviour
steps 1 - 5 are all as expected. Step six should be
app redirects to Salesforce oauth provider sign in page, in unauthenticated state (ie no cookie or session data that was previously stored is still valid)
user is required to re-enter their credentials
oauth flow takes over and redirects the user into the app if the credentials were correct.
Actual Behavior
as per initial steps where the user is not even asked to enter their credentials (step 6):
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Reproducible Demo
The code is in a private repo so I can't share details of it, but it's a very standard oauth flow, and seeing it's happening in all three of the method calls from the top suggests to me that it may be due to something in the WebBrowser.openAuthSessionAsync implementation. I have seen on the apple developer docs that SFAuthenticationSession has been deprecated in favour of ASWebAuthenticationSession. My understanding is that this (SFAuthenticationSession) is the browser used by expo's WebBrowser and the wrappers mentioned above (AppAuth and AuthSession) for the oauth interactions. I also see that it mentions it's for a one-time login, which perhaps explains why it would hold onto any session data and jump to the conclusion of re-authenticating without directly seeking credentials from the user, but it seems unhelpful to store a cookie without validating it, which is what appears to be the end result.
Notes
Essentially this is making it impossible for a user to sign out of our app, because the system browser, that we don't have control over, is keeping track of their authentication despite the session value no longer being valid against the server.
I've seen other people looking to find ways to clear cookies from the system browser, which may be what this issue relates to, though it doesn't appear to be possible to access the auth session's browser cookies in any way. This comment on a GitHub issue is exactly what I'm experiencing and need to find a solution to.
I would like users to be able to sign out, and then when they sign back in again they should have to enter their credentials again. Does anyone have any thoughts as to how this might be possible?
On iOS, it's now possible to pass in the following config to WebBrowser.openAuthSessionAsync to essentially treat it as incognito and ensure it doesn't retain any cookies. The effect is that the user will have to re-authenticate each time (even if there session is still active). I'm not aware of a similar approach for Android, however.
Code
const browserOptions = {
preferEphemeralSession: true
}
result = await WebBrowser.openAuthSessionAsync(authUrl, redirect, browserOptions)
I was looking at Khan Academy and I'm wondering how their authentication works (probably many other websites have it the same).
When you login with facebook account that has email "aaa#gmail.com", you completely logout, open another anonymous window, and login with google account that has the same "aaa#gmail.com" email, you log into the previously created account.
My questions are :
Do they make association to account based on email your social account has ?
I'm sure their solution is secure, but is this common and normally doable so there won't be any possible exploitations ?
I'm using a system of Oauth2 to grant access to my app, dvouch
First you have a registered user in your website, with an unique email.
So what basically happens is:
User visits your website (website doesn't know who the user is)
User clicks to login through one of the Oauth2 providers
Your website proceeds to start a "OAuth2" handshake, it redirects the user to the provider oauth endpoint, along with some information, like what scopes you're asking for (email, personal info, public info, etc), the url to send back the user after the authentication is done, your application tokens (that are registered in the providers app dashboard), and so on.
Let's say the provider you chose was facebook. Facebook receives your request for an OAuth2 authentication. It also receives the scopes you're asking for, which url you want the user to go to after being authenticated, and your application credentials
It checks that the credentials you're sending are valid, that the callback url you're asking the user to be sent after also matches what they have registered for your app (so that someone can't simply steal your app credentials and have users redirected somewhere else) and if everything is fine and dandy, it will then present the login window to the user. This login is happening on the provider's page. Not on your website.
The user logs in (inside facebook or google not your website). The provider sends them back to the call back url you specified in the beginning of the handshake.
You (your website) receives the user back with a bunch of information, such as the email of the user who just completed the Oauth2 flow.
At this point you use the email that came in the callback and identify the user through the email. Since all emails are unique, and since your user had to be registered with that email on the provider, you are safe to assume he's the owner of the email.
(technically things might happen a bit differently)
It's basically very secure as long as the website has the regular security measures. Of course if someone has access to your Facebook(wtv) account or email they can login as if they were you, but that would happen either way they offered Oauth or not.
Then as long as you verify you're logging in the correct provider's website (like facebook's or google and not something else) you'll be fine since no one else will be able to see your login. Since a "scope" of authorizations has to be passed as well you as a user can also see what the application is asking for (email, access to your inbox, wtv) and decide if you want to grant those scopes or not, if you decide not to grant access then facebook will not pass back that information, which in turn renders the process safe.
The only way it wouldn't be safe would be if you had malicious software installed in your computer to log your activity and in this case you would be screwed either way.
We are trying to build OAuth2 Authorization with IdentityServer3.
So we downloaded the Bytes from nuget and connected it with our database.
The database was initialized with the default scopes and the sample clients from Thinktecture self.
Then we connected AD FS as IDP via OWIN and made an simple ExternalUserService.
So far everything worked fine and the permissions page of the IdSrv could be opened, showing the username and that no application has consent up to now.
Then we tried to connect Xamarin.Auth to that and got an error Cannot determine application to sign in to and in the logs an error Signin Id not present (after logon at the ADFS IDP).
To reduce complexity, we decided to go back to the InMemoryUserService and created one InMemoryUser. This worked for the permissions page (at least for a short period of time - time is over now), but it did not allow OAuth2 Authorization Code Flow, which ended up in showing the login page again and again and again. And there is no evidence of any error in the logs.
How can we debug, what is happening? Is there any way to see, why a user gets redirected to the login page again despite being logged in?
--
We reduced the complexity even further by creating a new empty MVC application, which just uses a simple InMemoryUserFactory.
Now it's getting a little bit confusing: one user was able to logon from his machine - other machines (same user - since we created only one) are not able to login and get prompted with the login over and over again.
If using IdentityServer3 and you use own external login methods you should really pay close attention to the API of the IdSrv3.
We tried to create a login resutl with just the subject - this is made for local login on the server. If this is switched off at the same time, you will end up having problems.
So if you use an own external login provider and switch off local login, make sure to call the right overload for the authenticate method (3 Parameters in our case).
I can not seem to find a SIMPLE answer to the question on how to persist OAuth2 authentication... Let's take Google+ OAuth2 API as an example.
User goes to page
User is not authenticated, and gets redirected to authentication page where he logs in
User logs in successfully and authorises my app
User gets redirect to specified (by me) URI with Authorisation Code
I use authorisation code to obtain a token in order to submit queries in the name of the user
All is good and well. My question is: how do you SECURELY know at step 2 that the user visiting the page is already logged in, without having to go through the whole process of redirecting him to all these pages.
I assume storing the Authorisation Code retrieved at step 4 in a cookie is not an option.
All of this will happen in a server-side (Go - if that matters) application.
Any help is much appreciated... I need a simple solution.
Thank you!
use server-side sessions to store any authentication state or even access tokens if you need them.
one solution is to use a database for session store (an encrypted cookie holds the session id)
and another is to use cookie sessions (encrypted cookies that hold the session data).
using encrypted cookies that only the server is able to decrypt should be safe enough.