I have an app with confidential PII (social security number, payroll information). I'd like to enable users to login with OAuth IDs (Google, Linked In) for convenience but require those accounts have multi-factor authentication enabled in the identity provider, i.e. fail the login through OAuth2 if the user hasn't enabled MFA in their underlying identity provider account. This allows me to avoid exposing my confidential information to a weak GMail password.
Is there any way to do this?
Unfortunately, no.
In the case of Google and Linkedin, the authentication level is not linked to a specific scope. The Oauth response doesn't specify either if the user used an OTP token or not..
Even if the user is enrolled in MFA, the user can register the computer he's using as a trusted one and in this case, Google will never prompt him for an OTP. This behaviour may prevent many users to access your application.
Actually, I believe you could check on your own session / token to see if it was done through Google, Twitter, Facebook, etc and then require MFA / 2FA / OTP on the first use of that token. Does that make sense?
You could run your own TOTP microservice using Browser Authenticator which has the components you need to generate and verify a key and token in the browser and Node Authenticator which has the complementary server-side code.
Just add your own storage mechanism and an https call to microservice, update the session / token, and viola, you've added two-factor / multi-factor / one-time password authentication right on top of them.
Related
I am currently working on a React-Native project with my own backend
I have to use OAuth2, but I want to have the user enter their name and password and not forward them to Facebook / Google, for example
Any help?
The only grant types that allow acquiring tokens without redirects are the client_credentials and the password (resource owner password grant). Both of them are only feasible if you are running your own Identity Server (like Keycloak).
For identity federation with external systems, you will always need a flow that redirects the end user (at the very least in an iframe). The user authenticates against Google, not against your system. Google then issues a Token, and your application can verify the token was issued by Google. A system without a redirect would be equal to each and every user giving you their Google password.
This is the kind of thing that OAuth2 was designed to prevent, and so it is not possible.
according to here (https://oauth.net/articles/authentication/) and many other things I have come across. OAuth is not meant to handle end user authentication. Reading through the article above and others while searching provides so much information at once from so many angles that it is hard to see through it all. ok...
Does this mean that...
A) The protocol itself is not intended to handle authentication, so therefore, OAuth client apps should inspect "who" can authorize users according to the OAuth providers?
If ONLY the user can authorize third party apps, then isn't the fact of receiving authorization from the OAuth provider in itself proof of authentication? (if this is the case, then can OAuth access tokens from places like Google and Facebook be trusted as authentications?)
B) OAuth client apps cannot trust authenticating users with OAuth, so therefore must provide another sound authentication mechanism alongside it?
If this is the case, then every site that I have clicked "Login With [provider]" (and no other complementary authentication scheme) has got authentication wrong?
It seems to me that if only trusted and specific OAuth providers are used, then this flow could infer authentication
App requests login with trusted providers
User is directed to provider to authorize (ONLY user can authorize)
App then requests and receives token from provider, and adds user to the app database if necessary.
Token is put into secure cookie or JWT and returned to the user to be presented on subsequent visits.
The purpose of OAuth2 access token is to delegate some access rights (scopes) from a user to a client application. So the application redirects the user to an authentication provider (OAuth2 server), which authenticates the user and asks the user (consent step) whether he/she wants to delegate some access rights (the scopes requested by the application) to the application.
If a client application receives an access token, it can get its meta data at the OAuth2 introspection endpoint - such as username of the user (resource owner). So this way, the OAuth2 can be used for authentication. But the main purpose of access tokens is to delegate some rights. For example if a third party application wants to save its data to a user's Google Drive, it needs an access token issued by Google with scopes that allow it to access Google Drive.
If you want to use OAuth2 only for authentication in your client application (to get identity of a user), you can use OpenId Connect (OAuth2 extension) and its ID token, which is in JWT format and contains information about the user that was authenticated the authentication provider. This is better suited for the "Login With ..." functionality.
I'm implementing Facebook and Google SSO on my website using custom workflow (redirect urls, parsing on server side etc. - no javascript) and I got to the point I have access_token, token_type and expires_in and from Google also id_token and I am confused what to do next to authenticate the user.
I read a little about authorization vs authentication, and that Facebook and Google SSO is OAuth2 which provides authorization, but not authentication, from which I understand that this way my web application is authorized to do something on behalf of the user, but I cannot be sure the user is the one who I think he is? My main source is this: OAuth Authorization vs Authentication
So, my question is, what should I do to be able to can consider the user logged in.
Thank you
In your case google (and facebook) is authenticators. This services just tells your application that user who try to login to your system is the one who he wants to appear.
Assume you differentiate users by unique email.
Your application flow should be next:
The user try to login to application using google Application do all redirection google flow stuff and gives you tokens
Application need to store this tokens for future use
Application check if this user's email presented in database
If email is presented and google returns tokens (google authenticate your user successfully) you can login user in your app
If email isn't presented in database but google authenticate user successfully you can store this user (with email) to your database - sign it up - this is new user in your system
Same flow with Facebook. Surely you can extend this logic to be more your application specific.
SSO and OAuth are different. OAuth is authorization protocol.
You are dealing Google and Facebook oauth.
OAuth
In case of oauth, after successful authentication(google/facebook) you will get access token. You can use token for maintaining the user session.
With this token user is authorized, Now you should check whether the user is present in your database, if yes then authenticate the user and redirect to your application.
SSO
SSO is user authentication service. There are way to implementing SSO like kerberos SSO, ADFS SSO.
We should never use OAuth2 access token for authentication.
For details, please refer
https://oauth.net/articles/authentication/
The OpenIDConnect, built on top of OAuth2, can be used for authentication.
Google supports OpenIDConnect
https://developers.google.com/identity/protocols/OpenIDConnect
The basic idea is Google will issue the client app (your application) a ID Token after the user has login his Google account. You can then extract user information (e.g. email, unique user id) from this ID token and proceed your login flow.
Good Evening,
My group is rolling out SSO - yay. We have several applications that directly authenticate with Box.com and all token refreshes are handled automatically. After we migrated to SSO, we didn't include these service (app) accounts in our AD, so they do not have access via the SSO gateway.
My (likely incorrect) understanding of how OAuth with an SSO provider in the loop works:
We can still start the OAuth handshake directly with box - but box will forward this request to the SSO provider. The SSO provider will then authenticate the credentials and pass back a "all good" to box, which will issue an auth_token.
This is based off of the following from box:
"If you authenticate your application via Box’s OAuth 2.0, your
application will automatically let the customer sign-on with their
company credentials, just like they do with every other Box
application. This also applies to popular commercial services like
Okta, One Login, and Ping."
https://docs.box.com/docs/oauth-20
As well as this photo:
So if the external applications' service accounts with Box aren't in the AD of the SSO (too many acronyms), they should not be able to authenticate right?
But these apps are continuing to be able to authenticate. They are able to refresh their token and continue accessing box, even after the migration to SSO.
Where is the flaw in my understanding? Will these apps need to be added to the AD, or does this roll out of SSO not affect any of our external dependencies?
Thanks!
Got an answer from box:
third-party apps and integrations use a persistent authentication
token model. This means that unless a user deliberately logs them out
of the app, or an admin inactivates or deletes their account, this
user will never have to re-authenticate after initial login. Instead,
the app/integration will refresh their tokens. Refreshing tokens does
not require stepping through the SSO login flow, while generating an
initial set of tokens does.
Changes in SSO status, whether between SSO Off, Enabled, and Required,
or between two different connections, have no effect on existing
authentication sessions. Users won't be forcibly logged out when SSO
is turned on.
Upon next login attempt will the new SSO flow come into play. In this case, these users were already authenticated into the integration
prior to SSO roll-out. The SSO change would have impacted behavior in
that these users would need to authenticate via SSO going forward;
however, due to the persistent authentication model, that "next login"
never actually happens, and these users can continue to refresh tokens
and retain access without ever being challenged to authenticate into
the IdP again.
is there a way to ask for an OAuth authorization without redirecting the user to the service and then back again to my app?
In detail, I'm creating a web service that need access to the Facebook Graph API, that requires the OAuth 2.0 authentication. Is that possible?
Thanks
The authorization request has to happen for an authenticated (by the OAuth provider, not you) account, and for security reasons the authentication has to be a direct interaction between the end user and the OAuth provider.
Of course, the provider might decide the user is already authenticated properly (there is a fresh auth ticket in a provider-specific cookie for example) and skip the authentication sequence, but there is no way for you to force it to take your word that the user on whose behalf you are requesting the authorization indeed is an authenticated user of the OAuth provider.