Identity and security overview
When it comes to security. There is a lot of guidance and also advice and commentary on why you should ...
For further actions, you may consider blocking this person and/or reporting abuse
KIller article! Thanks.
Awesome article! A little question if you don't mind. Should both the access token and refresh token be saved in the http only cookies? I have an express server that provides the tokens, and a nextjs bff. And I'm not sure if nextjs should store both of them in http only cookies, or encrypt them somehow :D
The think about BFF is that you do not store Access or Refres Token in client cookie at all... Client have only session cookie and make request to BFF =>The BFF adds data to request like accesstoken (that is stored on BFF server side) => and proxy request to API...
In case token is invalid BFF req. automaticaly new token From ID provider... Client have no idea what is happening behind the scenes.... Client have only session cookie...
In case your NextJS is BFF server it store access and refresh token in some DB/Table (SessionStore) and with all requests looks on client session cookie based on identifier search for token in this database/redis and adds this to request and query that from API.... basicaly BFF is some man-in-middle... But it is server side so thats main reason why it is more secure like storing this data on client...
Important:
Clinet <> BFF -> Session cookie (no tokens just BFF client identifier)
BFF <> API -> BFF proxy request to API and adds access_token to headers...
BFF <> IdentitiyServer -> Query refresh token automaticaly...
Refresh token is holded on BFF and only used for renew and deleted on logout... (invalidated). You dont send refresh token to Client or API... Only to ID provider to renew...
This is much clear now. Thank you!
In the case of my SPA application not having a login and password, how do I ensure the security of requests between my SPA and BFF without storing tokens on the SPA side? This has been my main concern, and I've been considering server-side rendering with Next.js.
Very nice article.
End user identity is contained in JWT stored in BFF(he is OIDC confidential client). I assume that API services are Resource servers.. My question is, what if we have chained API service calls one after another(API Service 1 i calling API Service 2), booth of them are Resource Server, how the edge cases are solved with JWT expiration, because RS are bearer only clients...?
Nice article!
I have a question for you. Do you put the identity server on a domain that is shared between the mobile app and the web?
Example:
login.example.com -> identity server
app.example.com -> BFF web
apimobile.example.com-> BFF mobile
Or put everything on the same domain:
example.com/ -> BFF website
example.com/login -> IS
example.com/apimobile -> BFF mobile
I usually use the first approach, for a user who logs in from the web. When you enter the mobile app and are redirected to login.example.com, you are already logged in.
I don't know if there is a better approach.
I personali had it under equal domain since Google cloud allow you to do this mapping domain>IP easy...
But most of companies use separate subdomain as identity.example.com... or (login.example.com)
If you use different domain you need to ensure CORS allow list is properly configured..
nice article!
nice article, waiting for the concrete implementation article too
Hi, Thanks for the article. I would like to ask the fate of the promised follow-up article. :))
Thanks a lot.
Nice article
Nice article! I have a question, if I want to create a MVC web app, where should I put it in the big picture?
BFF works as proxy (gateway) you can put it behind BFF as another service with index redirection... In simple apps where you wana save services you can integrate it to BFF similar as SPA can be served from BFF...