Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).
Related
All my questions may sound fool, but I'm learning keycloak, and I have some questions about it.
Is it ok to have 2 realms, one for my backoffice(staff) and other for end-users(customers)?
the realm staff will only login using google federation (will only accept email of my company), and I will use the power of SSO in all software my company uses, this realm won't allow self-signup. (for this case it's OK)
in the other side, the realm customer (for end-user), the registration is open for everyone, they can use google and facebook, as well as plain password and e-mail. Also my platform have a native app (iOS and Android), and the customers will login/sign-up via API (native login and signup screen with textfields)
Does it make any sense to use keycloak for customers?
Thanks
Can we get credentials for the Google Calendar API on different devices?
We are using the Google Calendar API on the Raspberry Pi with the following steps as a reference.
https://developers.google.com/calendar/quickstart/python
We have generated the credentials by operating in the following steps
We chose TVs and Limited Input devices as the application type and then downloaded the JSON file.
Credentials > Create credentials > OAuth Client ID
https://console.developers.google.com/apis/credentials
Our Raspberry Pi does not have a keyboard and display.
We note the URL displayed in "Please visit this URL to authorize this application" via ssh.
We access the URL from the PC browser and note the authentication code after tying it to the calendar.
To "Enter the authorization code" we enter it.
It works as we expect.
But this is difficult for our customers.
Can we do this authentication using a PC or smartphone?
In that case, how do we move the token.pickle from the PC or smartphone to the Raspberry Pi?
Maybe we are thinking too hard.
If there is an easier way, please tell us about it.
We just want to use the Google Calendar API.
If you don't have a G-Suite account use SSH in order to send the tokens
Once you get the token.pickle you won't need to "visit" the URL to authorize the application. Anyway, a refresh token has its restrictions. A refresh token might stop working for one of these reasons:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
Use a service account instead (G-Suite account only)
The token.pickle is generated the first time. The quickstart you mentioned makes use of the user credentials. However if you want to use just one token along the devices and see a different calendar in every device I strongly recommend you to use a service account and enable the domain-wide delegation in order to impersonate the user's calendar.
To do so:
Create a service account
Enable the domain-wide delegation
Impersonate the user in order to see the desired calendar (using Python)
Reference
Refresh token expiration
Creating a service account
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.
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.
There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.