Alright! I just brought this up because in this case you will also need a client_id and a client_secret and finding the right place to store them in order for the oauth server to be able to issue a token is a nightmare!
Well ... if you use a client_id with secret, then this should be in the backend. Otherwise use the user grant flow or use both to have it (like in azure) validated as the intersection of user and application rights.
If you put the client_id and it’s secret into the web front end and use this as the only access restriction, you might as well use an API without authentication/ authorization.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ahhh... In the front end scenario, there is OAuth2.0 to validate the user context and grant access. Then the backend(s) accepts that token.
But these kind of credentials are not the focus of the article.
It is intended for backends to keep your credentials out of code.
Alright! I just brought this up because in this case you will also need a client_id and a client_secret and finding the right place to store them in order for the oauth server to be able to issue a token is a nightmare!
Well ... if you use a client_id with secret, then this should be in the backend. Otherwise use the user grant flow or use both to have it (like in azure) validated as the intersection of user and application rights.
If you put the client_id and it’s secret into the web front end and use this as the only access restriction, you might as well use an API without authentication/ authorization.