We're currently using ABP 7.3, .NET 6
I found this article
https://pulsesecurity.co.nz/advisories/aspnetboilerplate-jwt
It mentions that a token is still valid, even after the user has been deactivated!
I'm not sure how to fix this or even that I should, maybe it should be fixed within ABP?
I logged in and got the token.
Created a call in Postman to test if I could execute an Authorized endpoint (using bearer token).
Then I deactivated the user by setting the field IsActive to 0 in the AbpUsers table.
The call to the endpoint was still successful, I would have expected it to fail.
Related
Problem: How to authenticate in MS Graph using Azure AAD access token.
Current flow:
My web app has AAD configured with "Log in with AAD"
If I log into AAD my demo app is showing and if I go to https://******.azurewebsites.net/.auth/me
then I get the access_token.
What I tried:
So I tried a couple of things and this was the last, I copied the access_token as code and tried to send it, didn't work.
I'm searching for a solution to silently use the already logged-in user and call MS Graph.
The reason for the error is that you have used the wrong code. Don't try to send the access token as a code, you should request an authorization code in your browser.
https://login.microsoftonline.com/{tenant id}/oauth2/v2.0/authorize?
client_id={client id}
&response_type=code
&redirect_uri={redirect_uri}
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345
In addition, redirect_uri is also a required parameter.
For the already logged in user you need follow the below steps for access:
Make sure you have enable the allow access token for the register app as below
Write code to acquire access token for the for the logged in user Reference
Now you can pass this token in other successive call to get the result.
Hi I have been using rest methods to integrate Google Ads API in C#. Everything seemed to be working fine but all of sudden I started getting 400 response with the error message.
{
"error": "invalid_grant",
"error_description": "Token has been expired or revoked."
}
As mentioned above that I am not using client library but instead using restsharp and testing all my end points using postman also.
Any reason why it is happening? My refresh token is also valid. I have been using this for one week. I have also not reached to the limit of refresh token as I have only generated refresh token 3 to 4 times when I was trying to set up the accounts.
I believe the validity of refresh token is life long then why it is happening?
I solved the problem by generating new refresh token using playground. The reason it expired because the publishing status of OAuth consent screen of my project was on testing mode.
If you are integrating an API, you need to apply publishing status for production to avoid manual generation of refresh tokens when it expires.
I have file called StoredCredential, in my Java project, if you have something similar, you can try to delete StoredCredential file and after rerun your code.
An alternative method is to re-new your Authentication Token. You'll first need to head over to "Credentials" at https://console.cloud.google.com/ .
After you hover over to your project, you should see a edit icon on the right most, click that. Once you enter that you will see the option: "Reset Secret".
After your reset is complete, make sure to save the project.
Then you will have to hover back to your project and click on the download icon on the right most. This will have you download the JSON secret token.
Replace that token and make sure to delete any other token related file such as "pickle_token" from your repository.
After you have followed all your steps, it may prompt you to re-login through google. And you are all set.
Keep in mind, the token expires after 7 days, if your project is in "testing" mode.
I have two accounts of DocuSign, both have the same config on the Setting section. But the first one even though expires of the trial still can send the envelopes. The second one gets invalid_request when I tried to get the JWT token base on client_id, user_id, and private_key.
Do we need to enable some config to allow it? Thanks in advance.
A couple of things:
Are you using a trial (login via www.docusign.net) or developer demo account (login via demo.docusign.net)? You should only use developer demo accounts while developing with DocuSign.
To get a free developer demo account click the link at the top right of the developer center page. Demo accounts do not expire, but their envelopes that are over 30 days old are automatically deleted.
invalid_request can be cause by a number of different issues. Additional information is available in the body of the response. Please see what it is and then edit your question to add the information.
Added
For JWT invalid_request errors, the recommended steps are:
Get the DocuSign code example running with JWT grant. For C#, this repo.
Once that works, you'll know that the problem is in your code, not in the settings of the integration key (the client id), the private key, etc.
Check that your computer's clock settings are correct--the timezone and the day/date. These are used by JWT.
Check that you are specifying a user's guid id to be impersonated. This is also referred to as a user's "API User Id"
Check the body of the API response for additional debugging information.
If you receive the error "consent_required", that is good news since it indicates that your JWT grant was correct, except that the person being impersonated hasn't yet granted consent to be impersonated. To fix, see this blog post.
I need help to obtain an authorize code, is there any way to get one without accepting anything or any window that pops up. I need this for my service as an automated process.
I tried like a thousand ways but nothing works.
Please does anyone know a solution?
As per the docs (http://msdn.microsoft.com/en-us/library/dn659750.aspx), you can use a refresh token if your app has offline access in its scope.
If offline access is set, when you retrieve your authentication token normally, you'll also get a refresh token. When the normal token expires, you can request a new one similarly to the first token, replacing the code query parameter with the refresh_token parameter.
To be clear, the process looks like this as per the docs:
Send your user to your web service
Direct them to the OneDrive authorise page with the correct parameters (make sure offline access is in the scope)
Wait for them to be redirected back to your app with the authorisation code
Exchange the authorisation code with OneDrive (using the oauth20_token.srf endpoint) to receive a set of tokens (one of these will be refresh)
Wait for the access_token you received to expire
Exchange the refresh_token you received for a new access token as per the "Getting a new access token or refresh token" section of the docs
We have some web services with OAuth on them.
I am required to run some tests against them, preferably in an automated environment without using a browser.
The problem is logging in.
Without using a browser, and with using DotNetOpenAuth and setting the HttpContext.Current manually, I seem able to do everything and get a request token and a verifier (I use a test username and password).
I believe the next stage is to get an authorising token. Unfortunatly, no matter how I construct the request, I cannot get it to work.
At the moment, using a WebConsumer (DotNetOpenAuth library) and calling consumer.ProcessUserAuthorization() results in an error:
DotNetOpenAuth.OAuth.Messages.AuthorizedTokenRequest message: oauth_verifier
Probably the whole approach is wrong, so any help/advice would be useful.
Thanks.
I would recommend you skip the entire OAuth handshake and authorization step by having a test access token and access token secret that your web service's token manager always includes. Then wiring your test to also have that token pair included in its token manager, and always using that access token when authorizing your outbound calls.
In the end, it was a problem with cookies not being stored properly.
I was losing cookies between the login page (where the user types their username and password), and the authorise page (where the user says it is okay to share details with the third party). The second page was doing an extra check to see if the user was who they say they were (reading a cookie value that the login page was meant to have written).
It was not really an OAuth issue, just something I did not understand in the Authorising page (which has since been removed anyway - c'est la vie).
I then had issues with the domains of the cookies (when the domain starts with a ‘.’). This post helped me:
CookieContainer bug?
I ended up copying cookies from one domain to another.