I understand that OAuth2 was designed to delegate authorization grants to specific resources, it alone is not an authentication protocol. However, the passport-github README states,

This module lets you authenticate using GitHub in your Node.js applications. By plugging into Passport, GitHub authentication can be easily and unobtrusively integrated [...]

The GitHub authentication strategy authenticates users using a GitHub account and OAuth 2.0 tokens.

By using passport-github in my HelloAPI, end users would be directed to GitHub's authorization server to start the 3-legged authorization_code flow:

  • First the user authenticates with GitHub and grants limited access to HelloAPI.
  • GitHub redirects the user-agent (browser) back to HelloAPI using a pre-registered redirect_uri. The redirection URI includes an authorization code, and optionally, a state parameter for cross site request forgery detection.
  • HelloAPI quickly exchanges the code for an access token, using the client_secret as a means to authenticate HelloAPI with GitHub. (Here too, I should include a state parameter.)
  • And finally, HelloAPI uses the token to grab whatever GitHub profile is associated with that token.

Here we assume that the token was not created by some other client and subsequently replayed to HelloAPI as an attack to impersonate a GitHub resource owner. By checking the state parameter, I think that is a safe assumption, but https://oauth.net/articles/authentication/ warns against doing so:

OAuth APIs do not provide any mechanism of audience restriction for the returned information. In other words, it is very possible to take a naive client, hand it the (valid) token from another client, and have the naive client treat this as a "log in" event. After all, the token is valid and the call to the API will return valid user information. The problem is of course that the user hasn't done anything to prove that they're present, and in this case they haven't even authorized the naive client.

So this is my hesitation in using passport-github: It uses OAuth2 tokens for authentication which is exactly what the experts warn against. Including a state parameter seems to secure this server-to-server authorization_code flow, but I'm not sure.

What am I missing? Is passport-github authentication secure, or is there any way to make a "Sign In With GitHub" feature secure?

  • The problem I see is that Step 2 is wrong. Github does not call the redirect URI, it actuall returns a response to the client with a redirect to the redirect URI. Also there is no state parameter in step 3. In step 5: You create a session token between your client and your HelloAPI.
    – Johan
    Commented Oct 24, 2016 at 9:16
  • (1) Thank you, I fixed the wording. (2) GitHub accepts a state parameter for both the /authorize and /access_token endpoints. (3) I agree. HelloAPI would create a token once the OAuth flow is complete - assuming it is safe to authenticate end users with passport-github. Commented Oct 24, 2016 at 14:47
  • @Johan, "You create a session token between your client and your HelloAPI." Are you implying that an initial, one-time use of the GitHub token is safe for authenticating the end user as long as HelloAPI issues its own token for subsequent requests? Commented Oct 25, 2016 at 13:51
  • 1
    If done right, yes. You would not want to re-validate a token against the ID provider on every call!!!! Basically you must apply all the same security measures to this token that you would apply to a session token in any normal Web application. Use SSL/TLS, For a web based application store it in an HTTP-only cookie with SECURE set on. For a native application store it safely.
    – Johan
    Commented Oct 26, 2016 at 5:55

2 Answers 2


I don't believe that the GitHub OAuth2 implementation supports your use case to authenticate users, so from both a security and maintainability perspective I don't think it is a great idea. From the first paragraph of the documentation:

OAuth2 is a protocol that lets external applications request authorization to private details in a user's GitHub account without getting their password.

My assumption in the discussion below is that the authorization code and access token in the GitHub OAuth2 implementation are opaque to your client.

In the GitHub scenario, we have the following OAuth roles:

  • Resource Server - GitHub server that provides profile information about users
  • Client - Your HelloAPI
  • Authorization Server - GitHub auth server
  • Resource Owner - Your application end user

The passport-github implementation authenticates a user by using the access token gained by your client as part of the OAuth2 flow and then requesting the user profile information from the GitHub resource server at https://api.github.com/user.

For example:

  1. Joe Bloggs logs in to GitHub via the redirect from your client.
  2. The access token that your client receives is opaque containing no information about the identity of Joe.
  3. You make a request to the GitHub resource server from your client to retrieve the profile associated with the access token
  4. Joe's profile is returned by the resource server and you assume that Joe is the entity that has presented the access token to your client.

The issue for me is that there is no direct 'evidence' as part of this process to ensure that the identity that authenticated to GitHub as part of the OAuth flow is the same identity that is returned in the profile information used to make your authentication decision in the app. For me this is a fail from an information integrity perspective, and so I would not consider this 'secure'.

Given that the passport-github implementation doesn't appear to be a supported authentication scenario by GitHub it also creates risk in the event that GitHub changes their implementation in any way. It is best to use supported protocols and use APIs for their intended purposes to ensure security and maintainability.


Yes it's as safe as any other OAuth login as long as you use security measures via SSL/TLS and as mentioned Github also uses HelloAPI which adds another level of security most other OAuth Login API's do not! Going by other sites that could be used, after doing some reading, it is as secure as you are going to get with this type of login!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .