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...
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!