Re:Introducing TAuth: Why OAuth 2.0 is bad for banking APIs ...
by uncleyo on Friday May 06, 2016 @04:11PM
(#11646419)
I understand that. Problem is that I can "steal" other dev's app client_id and use in my app. So it seems impossible to use such client_id for auditing/evidence. With a web client I cannot do that since I don't own the domain, so I can be proven to be a party in some transaction
Re:Introducing TAuth: Why OAuth 2.0 is bad for banking APIs ...
by blazespin on Saturday May 07, 2016 @05:17PM
(#11651383)
They should allow for push notifications. That'd be more secure
At the end of the day though, everyone has to sign their apps with certs that are pretty well validated. So, it really cuts down on funny business like you mention.
1) You create a "normal" client in Google Developer console (i.e. a web client) 2) You create a native/Android client in the same project. This client is shared across all phones. 3) You add a scope of audience:server:client_id:$NORMAL_CLIENT_ID to auth requests from the mobile. 4) You get back token minted for the web client, from the native client!
This is how it works:
https://developers.google.com/identity/protocols/CrossClient...
The reason it is safe is because you can only do the cross client stuff from a mobile client, which disallows any redirect urls except for localhost and a couple of other special URIS (see https://developers.google.com/identity/protocols/OAuth2Insta...)
It's ok that the secret is not really secret because it's not possible to use it to making a Phishing site since the redirect URL is localhost.
I guess that doesn't answer your "how does it identity the app developer" but it does tell you how these things are deployed at least, and the important fact that there's just one client (not one for every device)