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 authorization server. Given that we have two sorts of clients one as defined by OAuth that is doing authorization only and one using the Connect extensions that is additionally doing Authentication I refer to them as OAuth client and Connect client. A connect client being a OAuth client using the Connect extensions for authentication (id_token etc). The connect spec calls it a client and as it is the connect spec the connect part is implied. OpenID Provider (OP) is a term going back to OpenID 1. Generic identity standards like SP-800-63-3 https://pages.nist.gov/800-63-3/sp800-63-3.html#sec3 Use the term Identity Providers (IdP) to refer to servers providing federated identity using any protocol. (Note to NIST the term Identity provider is used but not defined in terms. Probably obvious to the authors, but not neccicarily to the reader😊 My point being that twitter, facebook and some others do not do OpenID Connect so are not technically OP. I could use relying while in the middle of a Fido meeting as a excuse but everyone knows that even if I had taken the time it would have come out about the same. Hope that helps. John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 26, 2017 7:03 AM To: ve7...@ve7jtb.com Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, And thanks for the prompt reply! > 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 issue tokens. (this gives > your backend API access to user info) I'm not sure I followed due to the use of non-standard terminology... What do you mean by "OAuth client" - the Relying Party? And what about AS? Is that the Authorization Server, Application Server, or what? (One of the frustrating aspects of learning about OAuth2 and OIDC is that not everyone uses the standard terminology.) > The other pattern is for the native app to be a Connect client to > Google or other IdP and then passes a id_token (not access token) to > your backend in some secure manor and your backend validates the > signature on the id_token and that it was issued to your client > (verification is essential) (the native app gets access to user info > api) You still have the problem of how you secure your API, as you > need to exchange the validated id_token with something. I thnk that > doing this securely winds up being more complicated than the first > option. The same problem as above. I cannot find "Connect client" anywhere on the OIDC terminology. And is IdP what the standard calls OP? I don't mean to sound ungrateful, but when a newcomer asks a basic question is usually a bad idea to throw a lot of jargon or non standard terminology at them... Best regards, Dario Teixeira
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
