I applaud the goal of simplifying authentication by wrapping with an easy-to-use service. But it's important to keep in mind that authentication is a subtle pro

I applaud the goal of simplifying authentication by wrapping with an easy-to-use service. But it's important to keep in mind that authentication is a subtle process, and a critical security component of many applications! It's essential to follow best practices, and for developers to understand enough of the interaction to be confident in an implementation. A few points to look out for after scanning the source for the project: * if your goal is authentication (helping a user sign in to an app using an external identity) you should be sure to use an OpenID Connect flow (requesting a scope like "openid"), and be sure to convey the id_token back to the app so its signature can be verified. * you should be sure to create a non-guessable "state" parameter when generating an OAuth authorization request, and to verify this parameter upon completion of the OAuth core flow. * your design needs to prevent a session fixation attack where a malicious user injects her own token into the callback url (tricking a user into signing into an app using the attacker's account, and potentially submitting data that the attacker can then access the) * it's best to avoid inserting an access token into a url (where it becomes part of a user's history, gets cached by proxies, etc) -- the OAuth code flow you're using avoids this, but then you turn around and inject the token into your own redirect