A mobile app that just used Google API only would/should register for a Google
client Id and use connect with Google.
A mobile app that uses only its own API should have a client ID from its own
authorization server, and leave it to the authorization server to deal with the
authentication.
It sounds like you are currently doing something like the OAuth resource owner
flow.
Is there a Authorization server currently associated with your resource server?
If so you can change the OAuth flow you are using to the code one as described
in App Auth.
You still need to authenticate the
Unfortunately RFC 6749 lacks a terminology section.
>From Connect we have
>http://openid.net/specs/openid-connect-core-1_0.html#Terminology
(AS) is a common abbreviation for Authorization server.
In sec 1.1 of OAuth https://tools.ietf.org/html/rfc6749#section-1.1
Roles are defined Client and
It depends on what you mean by browser based apps.
In general for single page apps that are java script executing in the browser
dom, the recommendation would be implicit flow.
These apps don’t by definition need offline access as they go away when the
user is not present.
We have talked
There are a number of patterns that people use.
I prefer the AppAuth pattern where the native app is a OAuth client to your
server and you are protecting your API with OAuth. Your AS becomes a
Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated or
local authentication to
I know of no IPR disclosures for this document.
I have none to make.
John B.
Sent from Mail for Windows 10
From: Hannes Tschofenig___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
PS Using PKCE S256 would prevent this attack on web server clients, as long
as the client uses a different PKCE vale for each request.Even if the
attacker can observe both the request and response, they would not have the
code_verifyer and if replaying the code to the client the client
