Re:Show HN: A microservice that makes adding authentication ...
by JoshMandel on Sunday February 19, 2017 @06:03PM
(#13682718)
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
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