Question: What is the difference between OIDCStrategy and BearerStrategy. Which one should I use?

[dhodgin]

The documentation could use some beefing up to explain the differences on the core readme file to explain what you get back in each authenticate callback for the 2 strategies and which use cases they should be used for.

I managed to make a sandbox app using the BearerStrategy but i haven't gotten the OIDCStrategy working in any way yet. I wanted to try to swap out the strategy in my sandbox app or possibly use both in separate routes to show and see how each is used but then i saw there are 12 config options in the setup and got lost. There are also 6 arguments in the callback function for the OIDCStrategy and no comment explaining what they are.

Even if the config options and callback arguments are commented it would still be very helpful to know the use cases for each to decide which strategy i should actually use and the difference between them.

It seems they both use OAuth and I see that the bearerstrategy expects a JWT token in the authorize header but I don't get what the OIDC 'object' is that is passed between client and server and how that model works.

Perhaps a brief intro in the readme and some links to external resources to help the end user choose appropriately. right now the readme just says here's a sample of bearer and here's a sample of oidc and that's it. very confusing.

[dhodgin]

I did find this great starting point that @brandwe already wrote a few months ago.

http://cudou.com/pages/dggfdibc-passport-azure-ad-which-strategy-to-use.html

You could expand on that and it would be very helpful to users who want to make use of this library.
(I would define IdP and MEAN and perhaps elaborate a bit on how angular is doing the openID Connect part for you and how that means the server should use BearerStrategy.)

I'm using the MEAN stack and adal-angular client side so from this post I understand this to mean adal-angular is performing the openID Connect part for me and when the id_token is returned as a fragment in the url to the client that token is the JWT token. The client cannot inspect the token because it is encrypted. It can only pass it along to the server to say "This is my token for authorization, I'm already authenticated". Authentication has already happened at that point. this is why BearerStrategy should be used server side to validate the JWT token and establish if the user has access rights to this resource?

We will have each user stored in our system and look them up based on email provided from the JWT token. (I haven't gotten scopes to work properly yet and seem to only be able to get email in the JWT for Microsoft accounts, not AD accounts, in the case of it being an AD account it seems the email is the 'upn' property).

An explanation of how all these dots connect would be extremely helpful in the readme.md to new developers not experienced in all this.

[polita]

Please update the readme with super duper helpful info.

[starlightyear]

Believe that open status indicates more modifications coming up in readme?

[polita]

@xerners Ping...

[JasonKleban]

Updated link: https://stackoverflow.com/questions/36653812/passport-azure-ad-which-strategy-to-use