OAuth2 User Login vs. Client Concerns about oauth2orizerecipes HOT 3 CLOSED

The android application for all users would be one client. Not one client for user. Same goes for the web application. That would be one client for all users of the web application.

For the browser if you're okay with one page load before the SPA experience, you would use the "code" grant type, and do one initial page load where you do the handshake with the OAuth2 server (which might be the same web application you're running or another web application behind the scenes).

If you don't want the page load at all, you would use "implicit" grant type. Then your SPA would be given the token directly in the URL header.

You register your web application as a client once and ahead of time with your OAuth2 provider.

from oauth2orizerecipes.

Ah, that makes more sense! @FrankHassanabad this repo helped me out greatly! The only thing I have left is to organize scopes on front facing gateway(s) and I'll be golden!

Out of curiosity, have you every heard of people using many different resource servers? I was playing around with the idea in my head today of breaking apart my SPA into many different apps for every section (think Dash, Todo, etc all being completely separate) and have resource servers for each one.

I saw a couple of examples of Service Discovery, and think that approach could be overly engineered with the amount of micro-services I think I'll end up having. I think I would have to map the idea out more, but seems like a clean separation of concerns. At the same time, my knowledge of Service Discovery is so limited it may be the better solution.

I only ask because of the nature of this repo! Thanks again for helping me out!

from oauth2orizerecipes.

Yea, I actually know a lot about service discovery and microservices. My most recent projects have been working with a lot of talented developers on different teams to break out multiple resource servers and give those servers identities.

We used Hashicorp's consul for service discovery, registration, and health and status. We gave the individual services their own client identities and Authentication for them to speak to each other. We ran into quite a few issues with consul but overall were satisfied with the results.

Now that I have a lot of experience with it, I wish I could be commissioned (or find the free time) to write about it as well as develop new tools around it using the Node ecosystem instead of relying on golang based tools and hashicorp.

Nothing wrong with their tooling, it would just be really cool to kick up some competition in the sphere.

I might in the future, as I regain more time regardless but no promises.

from oauth2orizerecipes.