In BCP 212 we currently recommend against using implicit flow for native apps (Section 8.2), due to the inability to protect against interception with PKCE. AppAuth iOS & Android don't implement it, and the JS version didn't initially although it was requested by users who needed to do implicit auth and was eventually supported.
To me the usefulness of implicit on the web is limited, as the code flow can be used for public clients anyway. The one place I've seen implicit come up in discussions was for situations where reducing complexity for third-party developers who needed to implement an OAuth server was a high priority (one less endpoint to implement). +1 to have language recommending against the use in most cases (without needing to exclude Nat's use-case). The code flow has better security properties, and reducing optionality in the spec reduces the surface area and simplifies implementations. On Tue, Nov 27, 2018 at 12:36 PM, John Bradley via Openid-specs-ab < openid-specs...@lists.openid.net> wrote: > I understand that, but hat is Nat's concern as I understand it. > > When we say no implicit people, have a problem because implicit is > imprecise. > > We are saying no AT returned in the response from the authorization > endpoint. > > Nat points out that id_token may contain AT for the self issued client. > > So unless we say that is OK if the AT are sender constrained we wind up > implying that a OpenID profile of OAuth is in violation of the BCP. > > I am just trying to make sure everyone is on the same page with why Nat > was -1. > > It really has nothing to do with the SPA use case. > > John B. > > > On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote: > >> Hi John, >> >> as you said, self issued IDPs (https://openid.net/specs/open >> id-connect-core-1_0.html#SelfIssued) are supposed to provide the >> response type „id_token“ only. I don’t think the proposal being discussed >> here is related to this OIDC mode. >> >> best regards, >> Torsten. >> >> Am 27.11.2018 um 20:54 schrieb John Bradley <ve7...@ve7jtb.com>: >>> >>> I talked to Nat about this a bit today. >>> >>> The thing he is concerned about is mostly around the self issued IDP >>> that doesn't have a token endpoint(atleast not easaly). >>> >>> The main use case for that is the id_token response type where claims >>> are retuned in the id_token. >>> >>> Because it is fragment encoded some people call that implicit. That is >>> not what we are trying to stop. >>> >>> In some cases in that flow there may be distributed claims returned with >>> access Token inside the id_token. I think most people would agree that >>> those should be pop or sender constrained tokens. >>> >>> In the case of self issued the RP would be a server and could do sender >>> constrained via some mechinisim that is yet to be defined. >>> >>> So if someone wanted to return a access token in a id_token to do >>> distributed claims I don't think we have a problem with that as long as the >>> token is protected by being sender constrained in some reasonable way. >>> >>> This is a touch hypothetical from the basic OAuth perspective, so I >>> don't know how deep we want to go into it. >>> >>> I think the point is not to accidently prohibit something that could be >>> done in future. >>> >>> I also think we should not conflate confidential clients that can >>> authenticate to the token endpoint with sender constrained/PoP clients that >>> can deal with bound tokens. Yes both have keys but it is better to >>> describe them separately. >>> >>> John B. >>> >>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab < >>> openid-specs...@lists.openid.net wrote: >>> Hi Nat, >>> >>> I understand you are saying your draft could provide clients with an >>> application level mechanism to sender constrain access tokens. That’s great! >>> >>> But I don’t see a binding to response type „token id_token“. Why do you >>> want to expose the tokens via the URL to attackers? >>> >>> You could easily use your mechanism with code. That would also give you >>> the chance to really authenticate the confidential client before you issue >>> the token. >>> >>> kind regards, >>> Torsten. >>> >>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura <sakim...@gmail.com>: >>>> >>>> I am not talking about SPA. >>>> The client is a regular confidential client that is running on a server. >>>> >>>> Best, >>>> >>>> Nat Sakimura >>>> >>>> >>>> 2018年11月27日(火) 16:55 Jim Manico <j...@manicode.com>: >>>> Nat, >>>> >>>> How is proof of possession established in a modern web browser in the >>>> implicit flow? >>>> >>>> My understanding is that token binding was removed from Chrome recently >>>> effectively killing browser-based PoP tokens. >>>> >>>> https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/ >>>> >>>> Am I missing something? >>>> >>>> Aloha, Jim >>>> >>>> >>>> >>>> On 11/27/18 9:00 PM, Nat Sakimura wrote: >>>> >>>>> I am actually -1. >>>>> >>>>> +1 for public client and the tokens that are not sender/key >>>>> constrained. >>>>> >>>>> Just not being used right now does not mean that it is not useful.. In >>>>> fact, I see it coming. >>>>> Implicit (well, Hybrid “token id_token” really) is very useful in >>>>> certain cases. >>>>> Specifically, when the client is confidential (based on public key >>>>> pair), and uses sender constrained (key-constrained) token such as the one >>>>> explained in https://tools.ietf.org/html/dr >>>>> aft-sakimura-oauth-jpop-04#section-5, it is very useful. >>>>> (Key-constrained token is the remaining portion of this draft that did >>>>> not get incorporated in the MTLS draft. ) >>>>> In fact it is the only viable method for Self-Issued OpenID Provider. >>>>> >>>>> So, the text is generally good but it needs to be constrained like >>>>> “Unless the client is confidential and the access token issued is key >>>>> constrained, ... “ >>>>> >>>>> Best, >>>>> >>>>> Nat Sakimura >>>>> >>>>> >>>>> 2018年11月27日(火) 16:01 Vladimir Dzhuvinov <vladi...@connect2id.com>: >>>>> +1 to recommend the deprecation of implicit. >>>>> >>>>> I don't see a compelling reason to keep implicit when there is an >>>>> established alternative that is more secure. >>>>> >>>>> Our duty as WG is to give developers the best and most sensible >>>>> practice. >>>>> >>>>> CORS adoption is currently at 94% according to >>>>> https://caniuse.com/#feat=cors >>>>> >>>>> Vladimir >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> -- >>>>> Nat Sakimura (=nat) >>>>> Chairman, OpenID Foundation >>>>> http://nat..sakimura.org/ >>>>> @_nat_en >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> -- >>>> Jim Manico >>>> Manicode Security >>>> >>>> https://www.manicode.com >>>> -- >>>> Nat Sakimura (=nat) >>>> Chairman, OpenID Foundation >>>> http://nat.sakimura.org/ >>>> @_nat_en >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> Openid-specs-ab mailing list >>> openid-specs...@lists.openid.net >>> http://lists.openid.net/mailman/listinfo/openid-specs-ab >>> >> _______________________________________________ > Openid-specs-ab mailing list > openid-specs...@lists.openid.net > http://lists.openid.net/mailman/listinfo/openid-specs-ab >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
