Workin on a JS back-end (NestJs), what is the best practice to combine API key auth for external server calls and JWT auth for internal server calls.
For example, using API Key force server to open CORS to every one which I don't want for my main server.
What is the best architectural pattern to mix these use cases ?
1 server for JWT (app - server) + 1 server for API Key (external site - server)
1 server for the two (open CORS + create 1 route for each auth strategy)
other ?
Related
I have a general question on token-based authentication. I've seen multiple guides that seem to say conflicting things, so I'm confused:
Question
Who should be responsible for creating the JWT, the app developer (via the app's backend server) or the auth server (ex. the Identity Provider)?
(1) Here [0], it explains that the developer needs to generate + hash the JWT and use that as the bearer token for any request. From there, the auth server can use the shared secret key to validate the token.
(2) Here [1], it says the auth server generates the JWT and returns it to the client once the login is provided + validated (no backend server involved on the developer's side).
Which one is correct? If they're both correct, how do I know which one to use?
My understanding:
(1) #1 above is one where the developer stores the secret in the backend server of their app. The backen serves as the middle man between the client and the auth server to make authenticated requests without exposing the secret + access token.
(2) #2 above is one where the app has no backend server at all (SPAs like Angular/React). The client interacts with the auth server directly (aka no secrets involved). Per [1], the IdP only uses the client ID, scope and few other things to generate a JWT.
[0] https://enable.cx.sap.com/media/1_uup99qpg (skip to 1:49)
[1] https://auth0.com/blog/handling-authentication-in-react-with-context-and-hooks/ (scroll down to the first block of code under "Add authentication to your app", where the Auth0 instance is configured)
Depending on the project requirements/budget/timeline, the JWT can be created by the developer, or it can be managed by a third party (e.g. Auth0).
Terms
Authentication Server
Receives user credentials (e.g. username & password)
Validates user credentials (e.g. compare username's stored hashed password in the database to the result of hashing the password from the request)
If token is valid, server responds with a token that is used to authenticate future requests (often automatically stored in a cookie in the client by passing it in the proper header in the auth server's response, which can then be automatically included with every request).
Can be written from scratch (allowing for more customization), or can be handled by tools such as Auth0
Scenario 1 (SAP)
This scenario involves making authenticated requests to a third party API.
Your frontend accepts user credentials
Your backend ("authentication server") validates credentials
Your backend responds with a JWT token, created using the RSA Key from SAP, your User ID from SAP, and likely the User ID from your backend server so that you can ensure that the user making a request to authorized to access the data requested. NOTE: Auth0 can be used to create the token, if it supports storing and passing custom values to the JWT
Your frontend makes a request to your backend, including the JWT
Your backend ensures authorization (Auth0 can be used if it supports creating custom logic for checking authorization), then makes the relevant request (based on the request from the frontend) to the SAP server and passes both the JWT and the API Key (stored on your server) with the request
SAP verifies the JWT, and responds to your backend with the requested data
Your backend then passes the relevant data to your frontend
Scenario 2 (Auth0) - YouTube Demo
This scenario uses a third party auth server to authenticate/authorize routes on both your frontend and backend (both of which will leverage Auth0 tooling).
Your frontend directs the user to Auth0's login page
Auth0 redirects back to your frontend, where it stores the JWT
When a user clicks on a button on your frontend that takes them to a different route (e.g. /profile), your frontend can use Auth0 to see if they are authenticated/authorized and extract relevant user data.
When a user clicks on a button on your frontend that makes an API request to your backend, it sends the JWT token with the request, which your backend uses for authenticates using Auth0, and then responds with the relevant data (if the user is authorized to receive it).
I have a Web API written using asp.net core. This API will be used to communicate with several other services registered in AAD, which all could be made using different technologies like an MVC application written in asp.net core or a single page application written in Vue.JS. The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
I have added API permissions for my API to my apps.
How would I achieve this? I'm currently sending an access token using the Authorization: Bearer access_token header from the client app to the API, but since the client app and the API aren't the same app in the AAD, it's causing issues.
Here's the flow I'm trying to achieve:
All of the requested apps require you to login to the AAD and when requesting data from the API, they'll send the JWT token, which then should validate the token before returning the requested resource back to the client application.
It seems you misunderstand something . You can register your each client as independent application in Azure AD , and assign access permission for your web api .
The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
SPA application use Implicit grant flow , so that it doesn't need the client secret when acquiring token .SPA could be independent app , you should provide client id when making authentication with AAD. After getting access token , you could create http request with Authorization: Bearer access_tokenheader for accessing your web api .
Each client(web/spa/native) will acquire access token for accessing web api . On web api side , you just need to validate the token .Validate the claims(issuer,audience) and signature .
I have a single page application and it has 4 servers. S1,s2,s3 and s4 and each run in different port. S1 has only one table that is usesrs where all the user credential will be saved for authentication. Now based on users credential I want to set guard on s2 to 4 so that in every ends point i will have some method which will check the jwt token. How can I achieved this? I mean from front end authentication will be done by server 1 but rest of the server will response if user is logged in and without jwt token server2-4 will not return any data. I believe for that I need to know how to communicate from two server. i will be glad if you let me the process.
You can set in front of your API servers another server - API gateway. This server could also validate jwt token and pass through your request to other servers. Or you should implement jwt validation on each server.
For single sign on (SSO) I have a single auth server (with user table) and multiple resource server (various web applications).
So far I have implemented JWT using Oauth 2.0 and got the access token from the auth server.
I understand from the OAuth 2.0 spec that the resource server now have to communicate with the Auth server to validate the token. Which is simple and can be done by just sending GET request to auth server at the endpoint users/me to get the user object along with other user scope.
Now coming to my point is the frequency of the Auth server call from the resource server. Calling auth server for each incoming request to resource server is not efficient and will create slowness because of the extra round trip.
How often should resource server communicate with the auth server? If not on each request then how do I persist the auth information?
I was thinking of using session on resource server but I am not sure if that is correct way to go.
If your access token contains expiry time, then you can restrict consecutive requests to your resource server for that much time. You can cache access token once obtain and other requests first lookup in cache, also you can periodically check whether access token is still valid or not.
My system has this architecture:
'Hidden' server A (written in Java) which allow connection only from server B. There is no authentication in A. Server A have very rich API
Server B (PHP, laravel5, MySQL) 'middleware' which have users table and which authenticate user using JWT
File Server C with frontend angular2 app which will use rich API (indirectly from server A).
Server B only authenticates users and should pass they request to server A with very simple mapping (almost one-to-one - only request URL prefixes can changes).
The Question is, How to make such mapping (receive, authenticate JWT, 'redirect' requests to server B, and give back a response from A to web browser) with the less effort in travel? Or maybe this architecture is not good at all?
Please give me an only idea and 'keywords' (not necessarily full implementation :P ).