-
Notifications
You must be signed in to change notification settings - Fork 10
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
Initial SSO chapter #191
Initial SSO chapter #191
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally this is a good approach, but we should battle-test it a bit with commonly used FE libraries like MSAL which has both React and Angular flavours.
If we are using AD, we will most probably use MSAL and we would have to see how we can use it with BFF and redirect-based flows.
MSAL also has a popup-based flow, but I guess that is out of the question because BFF flow could only work in a redirect-based flow.
|
||
#### With server-side rendering | ||
|
||
When we're working on an app that might do API calls fro the server (e.g. fetching data for the server-side render), we need to have the token available on the server, which means that the cookie is the only option. In this case, we can use the approach the specification calls ["backend for frontend"](https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-10.html#section-6.2). In general, that means that our backend is the SSO client and it should create a separate session for our client code: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, that means that our backend is the SSO client
I would maybe clarify here that by "backend" you mean BFF backend that was mentioned in the previous sentence, and not the "core backend" that BFF connects to
I'm not convinced MSAL is a good solution:
|
Is there some FE lib that we are ok with using for standard OIDC flows? I can speak for Angular that, if using AD, MSAL makes most sense. For other providers, we can use angular-auth-oidc-client. We used We could probably do the same with MSAL, but I am not 100% sure. Note: Based on some examples, |
angular-auth-oidc-client is another example of a lib using localStorage to store sensitive credentials. The CEERIS approach is good, but it might not be possible or practical to do this in other cases (e.g. with microservices). Basically, there is only one client side way to do this securely, and that is with service workers. I didn't find a good lib for this, but I'm working on something for that). |
The goal of this chapter is to explain how to work with auth (right now the focus is on sso).
Once we have libs for this, we could also add more specifics for them.
New chapter PR:
https://github.com/infinum/frontend-handbook-private/pull/76