The README implies that the URL returned from openAuth should return a long-term access token via the lines
// Validate the stored access token (Maybe with a request)
and
if (code) {
// Get and Save the access token request, user info...
}
This is dangerous for developers who don't understand the OAuth flow as they may be tempted to return the permanent access token from a successful web OAuth authorization flow, which could be intercepted by a malicious developer and used to gain access to client resources.
The current gold standard for OAuth2.0 is to return an authorization code in the deeplink redirect and PKCE to exchange for the true access token. The openAuth documentation should ensure developers know this, preferably with some scary language in the example portion of the code around deeplinking, e.g. "DO NOT return any permanent secret tokens in this deeplink redirect!"
As detailed in Stytch's blog post on PKCE and You're probably doing oauth wrong on android, there are still vulnerabilities with deeplink redirection even when using App-claimed https scheme redirects.
The README implies that the URL returned from
openAuth
should return a long-term access token via the lines// Validate the stored access token (Maybe with a request)
andThis is dangerous for developers who don't understand the OAuth flow as they may be tempted to return the permanent access token from a successful web OAuth authorization flow, which could be intercepted by a malicious developer and used to gain access to client resources.
The current gold standard for OAuth2.0 is to return an authorization code in the deeplink redirect and PKCE to exchange for the true access token. The
openAuth
documentation should ensure developers know this, preferably with some scary language in the example portion of the code around deeplinking, e.g. "DO NOT return any permanent secret tokens in this deeplink redirect!"