I have a old JHipster 7.2.0 application that works just fine, but I want to set up a CDN (cloudfront)
The application works fine if I use the https endpoint, it use a JWT token.
But when I use the cloudfront endpoint, the /api/account always return 401
{"type":"https://www.jhipster.tech/problem/problem-with-message","title":"Unauthorized","status":401,"detail":"Full authentication is required to access this resource","path":"/api/account","message":"error.http.401"}
The content caching is disabled of /api/* request, and /api/authenticate is working fine
I see that Authorization header is send with a correct value, I don't understand how a CDN affect to JHipster JWT auth process.
Any hint?
Related
In my current application after the users logs in with google (passport strategy), I generate a JWT token on the server and then I have no idea how to send it back whilst also redirecting the user to the front end website.
While searching I read that the front end should fetch the token but does that mean I have to cache the JWT until it is requested and set some cookie with the key to get the token in cache? I tried doing that but that felt like I was reinventing the wheel and opening my self to some security vulnerability.
Unfortunately, the accepted answer does not seem to answer the question.
It is a good answer for sending from the frontend (e.g. web application) to a backend (API or similar).
But I understand that you want to send the token from the backend to the frontend.
In this case, there are several way to transmit that token. They are widely used by OAuth2 Framework protocol.
Using a callback Uri
This is one of the most used technic. The backend sever generates a redirect response (status code 303) with the token in the query string. As an example
HTTP/1.1 303 See Other
Location: http://frontend.org/?token=xxxxxxxxxxx
You can also use a fragment property
HTTP/1.1 303 See Other
Location: http://frontend.org/#token=xxxxxxxxxxx
Code Exchange
Another method very similar is to generate a unique and one-time-use code that will be exchanged for the token using an additional request.
HTTP/1.1 303 See Other
Location: http://frontend.org/?code=xxxxxxxxxxx
On the fronted side, get the code and ask the token to the backend (using fetch)
POST /give/me/the/token HTTP/1.1
Host: backend.com
Content-Type: application/json
{
"code": "xxxxxxx"
}
Possible Threats
There are several threats you have to consider. They are described in RFC6819, but mitigations exist.
CSRF attacks: Use a state parameter should be used (section 3.6)
Open Redirector attacke: you should not allow client to decide the redirection URIs (section 4.1.5)
In addition, you should have a look at the RFC7636. This specification defines a way to protect the code against theft by using a random secrt generated on client side.
You can send the JWT token in header or as a payload, and at the frontend you just need to attach the JWT token with every request when sending it to the server. The server should have the logic to validate before passing the request to next middleware if the token is valid the request will be passed to next middleware else unauthorised will be return.
You can send the token in headers, payload, query whatever you like, but widely people attach token in header under Authentication.
I recommend you checking this link, it has step by step process to send and validate JWT token with Node and Express.
You can also check this for node and react.
I have set up an instance of Azure FHIR with an Azure FHIR proxy using this tutorial:
https://github.com/microsoft/health-architectures/tree/master/FHIR/FHIRProxy##configuration
I am unable to call the proxy without getting the following error message:
You do not have permission to view this directory or page.
I have created a token successfully using the following tutorial:
https://learn.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial
I have created an app service principal in Azure with the permissions to access the FHIR proxy:
https://func-fhir-proxy-2.azurewebsites.net
I am generating the token using the following in postman:
Auth URL: https://login.microsoftonline.com/e34c8e67-182a-4085-9dc0-39a38dddea12/oauth2/authorize/?resource=https://func-fhir-proxy-2.azurewebsites.net
Access Token URL: https://login.microsoftonline.com/e34c8e67-182a-4085-9dc0-39a38dddea12/oauth2/token
Client ID: 4d138742-44c0-42cb-9878-8647a1d2ef17
Client Secret: Well..that's a secret!
Scope: openid profile
State: 12345
Postman returns 3 tokens: Access_token, Refresh_token, Id_token.
I have tried each token and all return the same 401 error.
ID token JWT looks like this:
I have tried calling the FHIR proxy API's, due to the tutorial I am not 100% which are the correct URLs:
https://func-fhir-proxy-2.azurewebsites.net/api/fhirproxy/Patient
https://fhir-test-apis.azurehealthcareapis.com/Patient/
None of this works, I just keep getting the same error. Does anyone know what I am doing wrong? Should I be calling the FHIR proxy API using the token? If so, why is the API not letting me in?
I managed to fix the issue. I found that the resource ID was needed in the auth URL:
This can be obtained from Enterprise Applications:
Also, creating two separate app registrations:
The link ending with ".../api/fhirproxy/Patient" is correct for the proxy deployment.
I'd suggest that you do a quick test that you can access the FHIR API without the proxy. You can use the existing deployment and follow instructions at https://learn.microsoft.com/en-us/azure/healthcare-apis/access-fhir-postman-tutorial.
Once you get that working, test the FHIR API with the proxy. You can start with the proxy that has the its security disabled (The FHIR api still requires security and you cannot disable it). Once you get that working, you can enable the proxy's security.
Since the proxy is a web app acting as a proxy, you will need two sets of credentials, one set for the FHIR api itself, which you specify in the proxy app, and one set for the proxy web app, which you specify in your client app, e.g. Postman or curl.
The reason for the error is actually very simple, you are using the wrong scope.
Usually the 401 error means that the audience of your token does not match your api. When you use the token to call the api, you will receive a 401 unauthorized error. The access token is issued based on the audience, so you must Make sure to set the scope to your api when you request the token. Of course you can also parse the token, check the aud claim, and make sure it is the api you want to call.
Therefore, according to your requirements, try to change the scope to: https://func-fhir-proxy-2.azurewebsites.net/.default
By the way, if you want to call api, you should use access token instead of refresh token and id token.
We have an IIS server running a EPICOR ERP system. The ERP system installs IIS application pool, which certain urls are remapped to be handled by the app pool.
Here is what it says about the verification:
For security reasons you should always use https with REST API
REST API supports 2 authentication methods Basic authentication The
username and password are combined into a string separated by a colon
and encoded using Base64. The result is placed into Authorization
header: Authorization: Basic {encoded string} Token authentication The
bearer token can be obtained for the user from token service. See
https://epicorapp2/ERP10.1Test/TokenResource.svc/help (Token
authentication should be enabled). Then access token should be send in
the Authorization header in the following form: Authorization: Bearer
{token string}
The IIS server itself has anonymous authentication for the top level url (and all others are turned off).
My experience in Chrome when I go to the desired URL:
https://epicorapp2/ERP10.1Test/api/help/
is that one gets a pop-up asking for username/password (where the user/passord is for the ERP system, not for the host IIS system).
But I am unable to duplicate this experience either with Postman or Insomnia
(I have tried putting in the username/password in the authorization options for both Postman and Insomnia. I get a 401 authorization error.
Any ideas?
Never got postman to work. But Insomnia works fine as soon as I was able to update the self-sign certificate to DigiCert.
I have a Lagom application in which I have enabled play security headers by adding play filters dependency in the project. Now, when I am hitting the service endpoint, it is giving the error:
p.filters.CSRF - [CSRF] Check failed because no token found in headers
I have in the play documentation that Play will require a CSRF check when all of the following are true:
The request method is not GET, HEAD or OPTIONS.
The request has one or more Cookie or Authorization headers.
The CORS filter is not configured to trust the request’s origin.
And all three are true in my case. Disabling csrf check is not an option for me.
I just can figure out how can I obtain this token to be sent in the header. Do I need to add anything in the configuration file?
Any help would be appreciated.
Disabling csrf check is not an option for me.
Why? Lagom is a framework for sessionless microservices. It's very strange, that you need CSRF token for calling Lagom endpoint. If you want to protect Lagom endpoint, you need to think about implement authenticating/authorize.
Need to get the authorization token to access my app running on localhost. I query the AAD token endpoint for the token from the Swagger OAuth2 client in UseSwaggerUi3. I get the CORS error that endpoint is not allowing the cross origin requests from my localhost. How can I fix this?
[Edit]
I'm able to get the token if I send a POST request to the same endpoint using Fiddler.
You can't use client credentials flow from the front-end. Firstly because your secret is visible to anyone who sees the page.
Secondly because Azure AD blocks cross origin requests to its token endpoint. (as you saw)
You need to use authorization code or implicit flow with user context. Or build another API which gets the token in the back-end and calls the other API with it.
CORS are the cross origin resource, it will allow two different web apps working on 2 different origin to communicate with each other.
There are two ways to enable cors
1) go-to azure - web apps - setting column search - cors.
2) add new cors header as "*", which means it will allow all the urls which are requesting the web app, you also provide specific one url.
3) save it.
4) second approach is allow cors header from your code in web config headers.