I think there’s no advice because it’s not different: you should still be using the state parameter. Just use a random value with high enough entropy, which is also what most web applications do (the advice in the spec is weird and I think a remnant of Bradley making things too complicated in his advice). In a web app, it gets tied to the session cookie back on the server, you don’t need any particularly fancy binding beyond your usual session management. In a native app, just store it in the application before you send it and look it up on the way back to make sure it matches. Combine this with PKCE and you’ve got a pretty solid set of protections for native apps.
— Justin > On Jan 19, 2016, at 10:18 AM, Adam Lewis <[email protected]> > wrote: > > Hi, > > I have not been able to find any usage for the state parameter in > authorization requests for native apps. Further, the spec guidance of using > a hash of the session cookie as the value of the state param doesn't apply > for native apps. > > draft-wdenniss-oauth-native-apps is silent on the matter. > > Usage of state seems to be unique to clients conforming to the web app > profile. > > Bottom line, looking to vet that it's safe to omit the state parameter in the > authorization request for native apps, and that I'm not missing something > critical. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
