Am a bit confused about the One tap sign in that was announced by google earlier this year. Our application already users Credential Management API in Chrome, which essentially provides the user with login options based on the credentials that user has saved for our site on previous visit (passwords that are saved in chrome). When I read the documentation for One tap sign in, it promises to do the same thing, but using Google's client api id. Our application has its own ID provider with our own database of user name and passwords, from the documentation it looks like One Tap sign in does not support custom ID providers. Can anyone shed more light on this, why would I use one against the other?
Thanks
Karthik
I see two major differences:
One Tap is passwordless - it uses a token based login that never exposes the user's password. Chrome Credential Management API stores and retrieves actual passwords in Chrome's password store.
One Tap is purely web based - Chrome Credential Management API relies on Chrome's specific implementation. One Tap is a purely web based workflow so it will work across browsers.
One Tap is a much better long term login solution in my opinion. The Credential Management API is experimental and currently only supported in Chrome.
https://developer.mozilla.org/en-US/docs/Web/API/Credential_Management_API#Browser_compatibility
I lead product development at Google for the one-tap/auto sign-in library, we designed it such that the library includes the Credential Management API and extends to provide assistance in account creation, secure passwordless, and cross-browsers support.
In particular, if you make a request for existing credentials with code like this:
googleyolo.retrieve({
supportedAuthMethods: [
"https://accounts.google.com",
"googleyolo://id-and-password"
],
supportedIdTokenProviders: [
{ uri: "https://accounts.google.com", clientId: "CLIENT_ID" }
]
});
then any saved username/passwords from the Credential Management API will be returned (in browsers supporting the API) along with token data for Google Accounts. The one-tap/auto sign-in JavaScript library wraps the Credential Management API for credential retrieval.
Furthermore, the library provides a googleyolo.hint method to show an email selector for one-tap selection of a verified email address to assist in new account creation, or to link to an existing account, and then be auto signed-in next time with token instead of password, across all browsers, so long as the same Google Account is active.
I'd suggest using the one-tap/auto sign-in library and consuming tokens as well as passwords in order to get assisted sign-up, keep existing users signed-in automatically, and provide functionality even if the browser does not support the Credential Management API.
As for the question about using your own database of username / password, the hope with this library is you could implement the ability to create accounts and auto sign-in to these and existing accounts with an OpenID Connect ID tokens representing the user's identity. With the one-tap / auto sign-in UX, these are not only much more usable, but far more secure then passwords and mitigate creation of weak/re-used passwords. Please consider this or, even better, a hosted auth solution like Firebase Auth or Auth0 and include the one-tap UX in the frontend UI.
Related
I am building an enterprise app and federating signin using the Cognito Hosted UI solution, and people can sign up individually using any email, but they might also work for a company which has signed an enterprise deal with us and use SSO.
The desired workflow is one in which they input their signin email, then it is checked against our list of SAML Single Sign On providers, and if they match an enterprise client using SSO they are sent to the proper federation page; if they don't match any, they are taken to the general purpose login.
So far, I have successfully used the Hosted UI and the critical idpIdentifier parameter to create the desired behavior successfully. The following React code summarizes how this works:
hostedUILogin() {
const idpIdentifier = this.state.email.split("#")[1];
let url = `https://${domain}/oauth2/authorize?response_type=code&client_id=${clientId}&redirect_uri=${redirectSignIn}`;
if (idpIdentifier) {
url += `&idp_identifier=${idpIdentifier}`;
}
window.location.assign(url);
}
This produces the desired effect. When somebody signs in with an email address that ends in "#corporatecustomer.com" they are taken to the SSO page for Corporation's federation. When somebody signs in with "#gmail.com", they are taken to the Cognito Hosted UI.
Unfortunately, the Hosted UI seems to be unable to help itself but to show off our customer list on the left-hand side.
I am unable to discover in the documentation or tutorials any way to use the Cognito Hosted UI without advertising all available SAML providers on the left hand side, thereby giving away our customer list.
I have tried taking away the IDP for this Hosted UI App in the App Client configuration, but then it no longer captures through the idp_identifier successfully.
If it helps to you, one of the solutions I found was to create a single User Pool per Corporate Customer
You can create different App Client, and you can enable only identity provider on the first one, and native username/password on the other one.
For each App Client, you can dynamically change your AWS Config on the client side.
On our use case, SSO users may not have the same identity provider name on their email domains so we have "Login with SSO" button, which first handles kind of "Home Realm Discovery" by sending a request to backend with user's email and that endpoint returns the identity provider name belong to that user. Then the client initiates the federated sign in (or direct call to the hosted UI with identity provider parameter).
I am looking to allow a user to sign in with github for a website I am creating that will be API driven. However, I am running into a problem that there seems to be no way of authenticating a user and getting their email and name without redirecting them on the current page to github. I have tried to create a popup, but there is no way for me to get the necessary data from the popup, namely an api token to be used for the next calls.
The answer to the question as framed is "use a different grant flow" but your questions tell me you don't understand OAuth grant flows so you may be better served by a lecture on OAuth.
Popups and iframes are specifically designed to prevent code running outside them from fishing out data, because if you could do it so could invisible iframes in dodgy ads. Give up on that approach because in the unlikely event that you find a way, browser makers will immediately take steps to prevent your solution from working.
The behaviour you describe sounds to me like implicit grant flow.
Here's a walkthrough of the various ways OAuth2 can work.
Why so many ways?
Implicit grant is a flow that uses redirection to deliberately take control away from your code - which might be compromised or impersonated - and give it to a trusted third party, the OAuth provider: GitHub in this case. You pre-register the point to which control is returned after authentication, the point of which is the token is always given to your code.
Amnesia, popups, and what was I doing before we were so rudely interrupted?
There are flows that use popups. Usually this is the authorisation code grant flow. Popups are not suitable for mobile devices and this led to the creation of the implicit grant flow.
The usual reason for not liking redirection is the amnesia it causes. The solution is to store app state persistently prior to passing control to the OAuth provider, and to write a return-from-oauth handler that unpacks the JWT from the redirect parameter and then restores the app state you saved.
Note to self
If the user is anonymous prior to authentication serialise your state to a string and put it in a cookie or in localStorage.
If the user is not anonymous and is authenticating to elevate privilege you'll have to send any privileged data to the server and just persist a retrieval token on the browser. You must ensure that retrieval of this state requires both a valid OAuth token and a valid state token, and that it discards the state after honouring a request so that a replay attack will be conspicuous (you'll have to handle the fallout).
Having acquired a valid token you can use it to request profile information from GitHub. A very small amount may already be present in the JWT; you'll probably have the email address that served as a login, but this isn't necessarily the right one for correspondence.
GitHub OAuth documentation
It appears GitHub only supports code grant auth. That means you have to do the popup/iframe thing. Here's their doco:
https://developer.github.com/v3/oauth/
Code grant - why?
This flow doesn't give you an encoded token, it gives you a code you can redeem for an encoded token. The idea is that when the token expires you can use the code to get a refresh token without sending credentials over the wire.
Not only you have a redirection, but starting Dec. 2020, you also have:
OAuth 2.0 Device Authorization Flow now GA
GitHub Apps and OAuth Apps now feature GA support for the OAuth 2.0 Device Authorization Grant, in addition to the existing Web Application Flow.
This allows any CLI client or developer tool to authenticate using a secondary system with a browser.
GitHub CLI uses this authentication method on the login command.
Read the full documentation on Authorizing OAuth Apps and Authorizing Users for GitHub Apps for more information.
Confirmed March 2022:
Enable OAuth Device Authentication Flow for Apps
From today the OAuth Device Authorization flow feature must be manually enabled for all OAuth and GitHub Apps.
This change reduces the likelihood of Apps being used in phishing attacks against GitHub users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication.
If you own or manage an OAuth App or GitHub App that makes use of the OAuth Device Authorization flow, you can enable it for your App via its settings page:
The OAuth Device Authorization flow API endpoints will respond with status code 400 to Apps that have not enabled this feature.
Documentation: "Device flow"
I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
I am using Azure MobileServiceClient to authenticate with a mobile app. I want to enable a secure logout function, which involves deleting the cookies created by the web component. Otherwise anyone selecting "Login" will simply get logged in if there's an unexpired cookie lurking around. Deleting the cookies is working great.
Unfortunately, it means that a user returning to the same provider on the same device has to provide their username again (clearly, I don't want to store their password).
I found out how to make it work with Google. (Google OpenId doc) I simply provide a dictionary of parameters to the LoginAsync method. That dictionary contains the key "login_hint" and the user's email address (which, btw, has to be valid to work).
This doesn't seem to work for Facebook, Microsoft or Twitter accounts and I don't know why. I read a document that said that "login_hint" or "username" was supported by convention, but none of that seems to work.
Anyone have any experience (even a completely different approach) with this they can share?
TIA.
In order to implement IdP provided solutions like that, you need to move to a client-flow authentication. Client-Flow is when you use the IdP provided SDK to authenticate the user. Once the IdP has given you a token, you pass that token (silently) to Azure Mobile Apps to exchange it for a ZUMO token that you can use with the Azure Mobile Apps service.
Once you have the client-flow enabled, you can do anything that the IdP (Facebook, Google, etc.) will allow you to do. It's not really an Azure Mobile problem - more of an IdP problem.
Use-case: Emails to be sent from a web-application upon an event, as someuser#somedomain.com via MS Exchange or Outlook.com, using the RESTful APIs exposed by Outlook.com. Only HTTP access allowed (=> no SMTP/IMAP).
All documentation seems to mention that the app has to forward users to MSOnline, sign-in and then use the authorization code sent back by MS online.
But, this won't work for a background task (=> no sign-in possible!) where a pre-built token(with some predefined scope) is necessary so that Outlook.com can be accessed via APIs to send mail as someuser#somedomain.com.
Any hints/pointers to how it could be done? Basically, automated authentication without explicitly signing in as 'someuser#somedomain.com' on the MS Online login page.
I did not find M$ documentation regarding Outlook REST APIs to be of any great help and found it to be pretty difficult to navigate/understand. :(
Thanks!
At some point you will have to have the user sign in to grant access to your app. So you would need to have some sort of user-facing web front end where they can do this. Once they have signed in and you've obtained an access token/refresh token, your background app should be able to use those tokens silently, without user interaction, at least until the user either revokes access or the refresh token expires.
Currently Azure (which provides the login/token functionality) does expire the refresh tokens after some time (90 days), at which point the user must sign in again to grant your app continued access.