Created issue here: GitHub issue 4716
Hi,
I understand that validation is also handled in back end, so this part can be considered secure.
However, access token endpoint is (also) called from front end which exposes the received access token (and id token containing all confidential data of the user) to the browser. I still think that the exposure is considered a vulnerability; it conflicts with the idea of authorization code flow where access token should be only requested by secure back channel and be kept solely in back end.
Hi @ismcagdas,
thank you for your answer. I have checked it again and I can confirm that it is actually the front-end calling the issuer's secure access token endpoint. See client browser's network traffic, step 1 and 2 are OK, but I don't understand step 3 and 4:
Why is it useful to additionally load openid-configuration and jwks.json from front-end side after we have recieved the token already? => I guess it is used for validating the token and to determine secure backchannel endpoint for retrieving access token, which should both be handled in back-end.
For those who face the same problem, follow this issue: https://github.com/aspnetboilerplate/aspnetboilerplate/issues/6371
Hi @ismcagdas,
can you please contact me at [email protected] in order to provide you access.
Many thanks!
Hi, yes, our DbContexts inherit from AbpDbContext.
