Forum Moderators: open

Message Too Old, No Replies

New API "Google Identity Services" With "One Tap"

         

engine

10:41 am on Aug 4, 2021 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



Google has announced its new "Google Identity Services" APIs consolidating the SDK, including "Sign in with Google" button, and "One Tap" authentication prompt which use secure tokens instead of passwords.

This might help reduce multiple sign-ups where users forget their credentials and sign-up again. Plus, it should provide a more secure solution instead of passwords.



Google Identity Services APIs.

Sgt_Kickaxe

6:16 pm on Aug 8, 2021 (gmt 0)



"By signing up for an account on our site you agree to give Google your password" might be a tough sell....

Robert Charlton

3:28 am on Aug 11, 2021 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



"By signing up for an account on our site you agree to give Google your password" might be a tough sell....
Sgt Kickaxe... I think you're probably right... that would be a tough sell. I'm guessing, therefore, that that's not how they do it. I don't find that idea mentioned elsewhere, in fact, but you might know about a reference that I haven't seen.

A further guess, and I'm not a programmer or a developer or a security expert, so I am guessing... but I"m thinking that this has got to be more like secure https... that some mutually agreed-upon identifier be used which neither party possesses alone... perhaps some kind of access token or session cookie. Again, this isn't my pay grade, so I'm guessing... but conceptually it seems to make some sense.

The developer documents mention something called OAuth, which I also wasn't familiar with, so I tried Google search to see what that might be. Huge amount of material on that. Here's a 3-min YouTube video which provides the simple analogy between an access toekn and a hotel key-card.....

"OAuth 2.0 access tokens explained"
https://www.youtube.com/watch?v=BNEoKexlmA4 [youtube.com]

I'm sure this is oversimplifying, and it leaves many questions unanswered... A big one, I'm thinking,'is whether this a Google-only approach, or has it found wide enough acceptance that other systems can use it?

I'm hoping that others looking for a solution rather than for an obstacle can jump in.

Also, I came across the Overview Page for Google Identity services, which links to several of the notes that engine references above... and that might also be a helpful way of getting into it, as that's where I saw OAuth mentioned....

Google Identity Services - Overview
https://developers.google.com/identity [developers.google.com]

NickMNS

4:38 am on Aug 11, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



@Robert Charlton
This refers to a concept called federated identity sometimes referred to as SSO (single sign on) but I think the concepts are slightly different.
[en.wikipedia.org...]

"By signing up for an account on our site you agree to give Google your password" might be a tough sell....

You should never "give" your password to any website. Passwords must be stored in the database hashed and salted such that it is impossible for anyone to see the stored passwords in plain text. The problem is that once you press submit on the sign-in form you have no idea how the data is handled. You simply can't know how every website is handling your credentials, but you can be pretty certain that Google is doing it as securely as possible and so using such a service provides a degree of trust and confidence for the user that cannot be had any other way. Not to mention that many people already have gmail accounts, so Google already has their credentials, thus there is no need to provide this data to others that risk misusing the data or being hacked.

This service are also offered by others, such as Facebook, possibly Twitter and Linked In, to name a few.

The real trust issue lies between the website and Google. Most directly, one needs to trust that the account has not be compromised and that Google (or any other provider) isn't authenticating user that shouldn't be, but here again it pretty safe to assume that Google will do a good job with this. Indirectly, each login to your website is logged by Google, thus providing them with yet more usage data. But really the biggest "trust" risk is that Google can for whatever reason decide to cutoff your account (as website using this service). As result, you will not only loose the ability to use the service but you will also loose any users that are signing with the service.

Ideally, one would need to develop a decentralized system, using blockchain technology, allowing users to store their credentials on a blockchain and then allowing the user to grant or revoke access to specific websites without ever providing their data directly to the website or app. With such a system no central party could control the data, and all parties (websites,apps and users) could interact without needing to trust each other directly (trustless). I believe that there are projects in development.

but I"m thinking that this has got to be more like secure https... that some mutually agreed upon mutually agreed-upon identifier be used which neither party possesses alone...

Typically these services use JWT tokens, which work very much like https.
[jwt.io...]

Also there is more information here about OAuth and OpenID (another standard).
[cheatsheetseries.owasp.org...]

As for the announcement by Google, "signin with Google" has been around for a long time, the one tap option seems to be the new feature, mostly UI from what I could gather but it looks interesting.

Robert Charlton

6:16 am on Aug 13, 2021 (gmt 0)

WebmasterWorld Administrator 10+ Year Member Top Contributors Of The Month



NickMNS... thanks for your extremely informative post, which gives me confirmation and background. I haven't yet had a chance to check out all of your suggested references.

I note this warning on the first one, and I'm wondering how much there is for a chance of a screw-up....
Warning: JWTs are credentials, which can grant access to resources. Be careful where you paste them! We do not record tokens, all validation and debugging is done on the client side.

I ask in part because I've just finished a long comment in Supporters about some urls that Google is picking up, and the user isn't yet sure where. Very different circumstances, I know... but one wonders why they would post this kind of warning if people weren't doing dumb things.

NickMNS

3:34 pm on Aug 13, 2021 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



but one wonders why they would post this kind of warning if people weren't doing dumb things.

The reason is that these tokens can be stolen. If you post a JWT token from one website to another then that other website can use your token to access the initial website. For this reason the lifespan of a JWT token is typically 20 minutes, after which a request must be made to the issuing website so that the token can be renewed.