My app uses a SPA client and Phoenix/Elixir backend, with jwt authentication (via Guardian library). The app is deployed using Docker on GCP.
I'm having the below issue:
I'm an authenticated user that has been issued a jwt. Everything works fine.
The production application's docker image is rebuilt, redeployed, and the server is restarted.
My jwt token issued before the rebuild is no longer valid.
I'm having trouble finding what would be causing this. Looks like the secret key used in config.exs Guardian config will always be the same across builds.
Any help is appreciated!
Either the contents of the payload are being used to validate the message, and some field has changed in a way that the JWT is considered invalid by the server, or the secret actually has changed and your assertion is not correct.
The way I would problem solve this is by using a pre-developed tool to verify the JWT. Either your secret key can be used to validate the signature or it can't. No need to "guess".
Related
Hi I am working on the mendix rest webservices and through swagger , i can test the local host data all right.
But when i promote objects to acceptance, i need to update the webservice seurity to 'Requires authentication'. This would need username and password.
when the webservices are in the UAT, it fails to autheticate the request as below shown. Can you please help if you have a solution in this situation?
thanks
This could be due to the Path based access restrictions in your cloud environment. Allow all access to the appropriate paths as below to verify your endpoints.
Restart your application after applying the changes.
Many of my (confidential) apps are talking to each other via the client credential flow.
They request a token from the Azure Identity platform and use this token to authenticate against another app.
A while ago I used client secrets to do so, but later I read that this is not recommended for production environments.
For this reason I changed to self-signed certificates that are valid a longer time.
Those certificates are generated by myself with Azure Keyvault.
However, also this is not recommended.
Microsoft states that that in production environments you should use certificates that are signed by an official CA.
If I now use Lets encrypt, this will expire all three months what is also not such a nice solution.
My questions:
Why is the client secret not recommended in production environments?
Why is the self-signed certificate a problem? I do understand this in matters of HTTPS, but where is the security breach if its used for client credential flow? In my case I am the owner of the app and the app registration.
Do I need to buy a certificate that is one-year valid to do it "the right way"?
Do you have any source of best practices here?
• Client secrets include application credentials, SSH keys, API keys, database passwords, encryption keys, connection strings and so on to connect various resources and access the data or functionality for achieving the designated purpose of that application. Thus, if these are breached, they can put your application at great risk of compromise. Also, the client secret generated in Azure AD and used in APIs for connecting to Azure AD for authentication and authorization purpose is listed and mentioned in unencrypted form in the API code itself. Though, we have an option to store that secret in a key vault and refer to that secret through either managed identity or RBAC assignments, but their credentials too can fall in wrong hands and let the application be vulnerable if the managed identity is a user assigned or even if then access scope of the secret is not well defined according to the required specific need. Thus, client secret is not recommended to be used in a production API.
• In client credentials flow, applications are directly granted permissions by an administrator to perform a certain action regarding the API to be called through it via certificate or federated credentials. Thus, when using a self-signed certificate in client credentials grant scenario, the administrator has granted the daemon app requesting access to other API all the required privileges regarding accessibility of code, API, permissions, data, etc. which can result in poor validation and misuse as the it is very easy to generate a certificate’s key pair without reasonable entropy. Also, protecting the private key of the key pair appropriately to its use and strong validation of the same is not promised in a self-signed certificate due to which it is not recommended in client credentials flow.
• For best practices regarding web app service deployment, please refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/app-service/security-recommendations#general
It explains the best security recommendations for deploying a web app service.
The Paypal API doesn't recognize my Client ID and Secret I got from https://developer.paypal.com/developer/applications/
I wanted to include a server side checkout according to this tutorial https://developer.paypal.com/docs/archive/checkout/how-to/server-integration/
When I do the request to https://api-m.paypal.com/v1/payments/payment I always get a 401 Error with the message "Authentication failed due to invalid authentication credentials or a missing Authorization header.".
I checked multiple times if my credentials were correctly included into the request. I also tested the endpoint in my server environment and as well via Postman.
I also tried the route https://api-m.sandbox.paypal.com/v1/oauth2/token to exchange my credentials with an access token and got the same problem.
I also tried to create multiple Sandbox and Live Accounts and always got the same error.
Has anyone an idea what the problem could be?
There are two separate issues here.
You first need to use /v1/oauth2/token to obtain an access token, and then use that access token to call any of the other actual APIs.
The credentials you obtain from PayPal Developer will be for either "Sandbox", or "Live". Make sure you choose the correct tab (sandbox, for development). Sandbox credentials will only work for api-m.sandbox.paypal.com , and Live credentials will only work for api-m.paypal.com . The two environments are completely separate.
If you still have issues, post the SANDBOX client ID and secret you are using, and the full request and response to the api-m.sandbox.paypal.com endpoint. There should be a PayPal-Debug-Id in any error response, in the headers if nowhere else.
Running into issues with multiple instances of IdentityServer4 on Kubernetes exposed by the load balancer. I dont think there is a issue with credential login, my issues are around JWT Tokens. Works fine when there is only 1 instance.
Overview:
IdentityServer4
MongoDB Data Storage
PersistedGrantStore
Data Protection setup on Redis
Multiple .Net Core 3.1 Web API. Using AddIdnetityServerAuthentication in start up passing in the connection and the API Name. I am running multiple instance of the API. Reducing down to 1 I still get the same issue. Works fine if there is only 1 instance of the Identity Server but multiple instances I get the following error on the API:
"Bearer" was not authenticated. Failure message: "IDX10501: Signature validation failed. Unable to match key:
I am not getting any errors or failed authentications on the IdentityServer logs.
So the questions going on in my head is, JWT token so in I believe the request should be validated by the token, i.e. the API should not be requesting info form the Identity Server? Identity Server has DataProtection setup running on Redis as its store, I can see its dropped info in there. I have persisted grants store, but tokens are not added.
Do I need to switch to resource vs JWT? What is likely overhead for that?
Are the tokens not getting shared between the API instances via Data Protection?
Thanks for any advice / suggestions.
In case anyone else comes across this. It was down to mistakenly leaving developer signing in the config of Identity Server. Replaced with a certificate solved the issue.
builder.AddDeveloperSigningCredential();
to
builder.AddSigningCredential(rsaCertificate);
We're just going live with the Intuit API feature on our live application. We finished the last step of the process by uploading the X.509 certificate signed by Comodo PositiveSSL CA. Though our production access status shows up as ready now, we are having a problem using the production OAUTH credentials. We get an unauthorized exception using these credentials. The development OAUTH credentials work fine though. We also tried using Thawte SSL 123 but no luck even with that.
Also, the actual expiry date of the X.509 certificate, we uploaded is 16-Mar-2014 but when we upload this to the Intuit settings page, it shows expired (0/1/1). Please advice.
Adding the update here to this question- issue was with pointing to the wrong PFX file.