Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for external IdP (e.g. Okta, Auth0, Firebase Auth, LDAP) #18

Open
mikesparr opened this issue Jan 28, 2019 · 3 comments
Open
Assignees

Comments

@mikesparr
Copy link
Owner

Many applications may use another identity provider (IdP) for login, and the app should trust the signed authentication from the provider, and create a user token/session accordingly. The 3rd party will need to pass the proper user ID for lookup.

At some point may want to genericize registration, login, logout to wrap external provider and keep IDs/sub in sync.

@mikesparr mikesparr self-assigned this Jan 28, 2019
@mikesparr
Copy link
Owner Author

Our systems should be the single source of truth so we should create, update, delete users from our systems and push updates to external provider via their API. This way if we ever change providers, we just have to pre-populate their data with a batch script and change destination API for ongoing events.

@mikesparr mikesparr changed the title Add support for external IdP (e.g. Okta or Auth0 or Firebase Auth) Add support for external IdP (e.g. Okta, Auth0, Firebase Auth, LDAP) Feb 6, 2019
@CorwinGray
Copy link

This is the best response to why not to utilize a 3rd party IdP. Thank you! I know it's been a couple years since you've had to look at this project, but I was wondering if you would be able to elaborate a little further about how to use this API framework to create a spash-page for the user creation/login?

It's easy enough to add a view engine and all of that to the express App, but I can't seem to figure out where to setup the initial render while utilizing the AuthenticationMiddleware piece that's already in place.
The "/" route by default requires an authorization token or immediately passes the "AuthenticationTokenMissingException", but wouldn't this route make the most sense for the location for our login/new user page? How would one go about handling the routing from there? Is that even the best practice for the render?

Is this something you'd be able to help me with at all, or should I just keep testing the layers until I can get something to stick? Any response at all would be amazing, and this whole project has been greatly appreciated! So thank you again!

@mikesparr
Copy link
Owner Author

Hi @CorwinGray - it's been a while indeed but thanks for the input and I hope this app is useful, minimally as a starting point to build your own.

This app is intended as an API backend only, so if I were building a frontend (UI) app it would typically be another repository and likely using NextJS/React like ( Example Web App ).

Your question about login can be complicated. Normally what I would do is provide a page with email/pass (assuming a non-OAuth workflow) and that page would submit to /login route in the API. The API would authenticate the user, and then fetch some data from the database and build a JSON Web Token (JWT) and sign it, usually including a user ID, their name, and perhaps some metadata.

The UI app would receive this JWT token, store as a secure cookie, and then redirect to another API endpoint passing that token in the header Authorization: JOIUWERLKJFLKJVLKJ234234vljad. Each subsequent request, the API app would validate the token and then perform the action requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants