@googlemail vs. @gmail

[daz]

Hey guys,

I've noticed a change in behaviour when users log in using federated Gmail.

Essentially, I think the domain for the email address provided used to be @gmail.com, and it's now been changed to @googlemail.com

Hence, users with accounts set to @gmail, are now automatically being created @googlemail accounts. In reality, they should be getting logged into their @gmail account. I was expecting consistency from the google / other provider side.

If I had thought about this - I guess I would have some logic in place to convert @googlemail -> @gmail always, but I thought this was pretty hacky and probably doesn't cover all cases.

Hence, what is the correct solution to this? Can I expect some consistency now?

I'm sure this applies to other email providers that offer multiple domains for the same inbox...

Kind regards,

Daz.

[Jin Liu]

Just for clarification - does the scenario below describe what you noticed?

- the user has @gmail email address

- the user clicks Gmail to start the federated login, typing his @gmail.com and password at Google

- your web server received the Google assertion and call GITKit VerifyAssertion() API

- the API returns a @googlemail.com email, along with other fields.

In principle, the 'identifier' field in successful VerifyAssertion response is the user's unique persistent identifier at the identity provider, and should be consistent even if the user's email changes.

[Daz Bradbury]

Hi Jin,

The scenario is more like this:

- User has @gmail email address

- Signs up and goes through federated login (clicking gmail button), redirected to google to confirm

- Our web server received the Google assertion and call GITKit VerifyAssertion() API

- The API returns an @gmail email, along with photo, etc...

--- All as expected up to here.
- The user comes to log in in 2 months

- Clicks on the federated login, redirecting to google

- Our web server received the Google assertion and call GITKit VerifyAssertion() API

- The API returns an @googlemail email this time, along with photo, etc...

Hence, it's not a discrepancy between what the user thinks / types, it's a discrepancy between what the API returns from the same account over time.

My assumption was the email would remain static (unless there is a big change like hotmail.com -> outlook.com) - this is false, so I'll have to re-think and rely solely on the identifier field.

Thanks!

Daz.

--
You received this message because you are subscribed to a topic in the Google Groups "Google Identity Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-identity-toolkit/yjUB9k9FEuE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to google-identity-t...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Darius Bradbury

Co-founder @ OpenRent
Phone: +44 (020) 3322 2733

[Daz Bradbury]

Hi Jin,

OK - I've updated my code so this should no longer be a problem as long as the 'identifier' field works as described. Makes sense, and I was naiive to think the email would remain static.

It might be worth making a note of this in the docs, although to be honest, I initially came across GitKit here:

http://havethunk.wordpress.com/2011/08/10/google-identity-toolkit-asp-net-mvc3/

And I guess I didn't test the theory enough in my rush to deploy.

I'll leave a comment exposing the weakness, but again, I think you should highlight this here:

https://developers.google.com/identity-toolkit/v2/reference/relyingparty/verifyAssertion

In the Notes: The verifiedEmail can change (@gmail / @googlemail for example), and only the 'identifier' should be considered unique and static.

Thanks,

Daz.

[Adam Dawes]

Thanks for the suggestion Daz. We'll update the docs accordingly. 

--
You received this message because you are subscribed to the Google Groups "Google Identity Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-identity-t...@googlegroups.com.

[Colin Rudd]

In my experience, the identifier field is just as subject to change.  When google changed from using the openID protocol to the OAuth2 protocol, all of the identifiers for gmail users changed.  So I thought, ok, I'll make the email the one field I can count on as static.  

Now, I'm not sure what the solution is, but it seems to me that if you know that x...@gmail.com has changed to x...@googlemail.com that is easier to adapt to than to try to match one random string identifier to a new random string identifier.

-Colin

Daz.

Daz.

To unsubscribe from this group and all its topics, send an email to google-identity-toolkit+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Darius Bradbury

Co-founder @ OpenRent
Phone: +44 (020) 3322 2733

--

Darius Bradbury

Co-founder @ OpenRent
Phone: +44 (020) 3322 2733

--
You received this message because you are subscribed to the Google Groups "Google Identity Toolkit" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-identity-toolkit+unsub...@googlegroups.com.

[Adam Dawes]

Colin,

You make a fair point that the identifiers have also moved around. But this only happens when their is a protocol change and I think we are very hopeful that authentication protocols will be stable with OpenID Connect going forward. 

Besides the complete domain change use case highlighted here, the intended reason for keying off of IDP identifier instead of email address is because users actively change their email address. The IDP identifier should be much more stable. 

To unsubscribe from this group and stop receiving emails from it, send an email to google-identity-t...@googlegroups.com.