Recently, Azure AD apps made some updates:
https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-breaking-changes#october-2018
Authorization codes can no longer be reused.
My question is should we handle with authorized resource which previously reused the code to get refresh token?
For example, I used the same code to auth https://api.office.com/discovery/
and onedrive resources, should those refresh tokens needed to be re-auth or something?
Thank you for answer.
If you already obtained the refresh tokens previously, you do not need to obtain new ones. You only need to ensure any code you have that would attempt to re-use an authorization code does not do this anymore.
Related
I want to use API in my .net WinForms application which are closed by JWT token. Such tokens can be received from the Identity Provider using Authorization Code Flow + PKCE. I worked with such flow before in Web Application and I know how to request code, exchange it on the access token and I used silent refresh approach to refresh the access tokens.
For my clientId I'm not able to use refresh tokens. So, I'm slightly confused how to implement to refresh tokens in the Winforms application.
It's definitely I need to open Login page to allow the customer enter credentials. Then I guess I need to catch code from the Redirect URL. It seems I need to use loopback IP address as a redirect URL and catch request in the application.
But how to set up refreshing process I have no idea. Please help with advice or add links to examples.
For a desktop app you should follow the recommendations from RFC8252. Without a token refresh you will get usability problems. Eg access token expires after 15 or 30 minutes, then user experiences a re-opening of the system browser.
This might be fine for a high security app, such as for banking, but for most apps it is not what you want. Alternatives such as long lived access tokens are bad from a security viewpoint, since the long lived value is then exposed on every API request.
You won't be able to use silent renew via hidden iframes either, since you don't have that much control over the system browser. You can only open it by executing a URL.
So you have these main choices, and maybe you can explain trade offs to stakeholders. You won't be able to implement a workaround in code:
No refresh token, and sub-optimal usability
Refresh token used, so a longer lived API credential is used in a public client
Locking down what can be done with an access token issued to the desktop app - using scopes and claims - is usually the main mitigation of this type of security concern.
I'm new to reactjs and I've ben trying to understand how the authentication token works to protect routes. In various tutorials people get that token from an api when logging in a user, and then store it along with a "isAuthenticated" variable set to true in localStorage. Then when routing they check if isAuthenticated is true, without any api call to verify the token. Is that safe? I was trying to implement authorization in the same way, by just adding some isAuthorized variable, but can't both of these be tampered with since react works client side?
Of course they can. Whatever is on the client is fully controlled by the user. There is no "client-side authorization". Such features (access control to certain functionality on the client) is usually a user experience feature, like why show something to the user that won't work anyway.
All authorization must be done server-side.
This inherently means that it's usually ok to have page structures (views) without data in the client for anybody to see, the point is that data from the backend will be authorized and will only be available to appropriate users.
I'm trying to do an Authorization request following the documentation about it on Microsoft (Getting access on behalf of a user: https://learn.microsoft.com/en-us/graph/auth-v2-user). I'm making the request using Azure's Logic Apps. I already made an app registration in Azure AD and gave it the following permissions (I used the app for a few different requests before so that's why it contains a lot of unnecessary api permissions). I already succeeded in getting access without a user (https://learn.microsoft.com/en-us/graph/auth-v2-service). Now I really don't know what I'm doing wrong, so if anybody has an idea of what it is, please let me know. I will try to explain as carefully as possible using screenshots so you guys get the idea of what I'm trying to do.
On the first screen below you can see the api permission I added to my app registration. For this request I'm only asking authorization for the one with arrow next to it(as you will see later on).
On the second screen you can see the HTTP post request I'm trying to make to the authorize endpoint. I blurred out the Tenant and Client_id for privacy reasons. I only added the required parameters in the body as described by Microsoft. In the scope parameter you can see the api permission I'm asking permission for.
On the third screenshot you can see the output of the request. Instead of getting an Authorization code as requested, I get an HTML body.
When I paste that HTML body into a browser it gives me the following result:
I have no clue what I'm doing wrong. I tripled checked to make sure cookies are enabled, made sure third-party cookies are not disabled and added login.microsoftonline to my trusted websites.
I'm starting to think I'm doing something very simple wrong, but I can't figure out exactly what. Any help is welcome! :D
Sorry can't add a comment so posting as an answer
What you are trying to implement is the Authorization Code grant flow of OAUTH 2.0. In Authorization code grant flow following steps occur
1) User is presented with the scopes that an application requires when accessing certain resources,
2) The user authorizes this. and the user is redirected to a redirect url
3) The application then exchanges the code sent with the redirect url to get the actual token which in this case will be sent to the Microsoft Graph for validation.
4) User then sees the information pulled.
The major crux of Authorization Code grant flow is that "User Authorization is required" This basically means that this flow is used when the call is invoked from a browser client where the user is actually interacting. This flow should not go through the Azure Logic Apps. If you want a service or a daemon to access the resources in that case you should use Client Credentials Grant flow
I'm getting invalid_grant error when creating a draft.
Scopes I requested:
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/contacts.readonly
https://www.google.com/m8/feeds/
https://mail.google.com/
https://www.googleapis.com/auth/gmail.settings.basic
https://www.googleapis.com/auth/calendar
I use python library to interact with Gmail API (
The main problem is that this sometimes works as expected, sometimes it doesn't work and I don't know why.
My code look like the one from example here: https://developers.google.com/gmail/api/v1/reference/users/drafts/create
Based from this thread, the possible problems that cause invalid_grant errors are if your server's clock is out of sync with NTP and/or you've exceeded the refresh token limit. This page also suggested to make sure that you specify access_type=offline in your request.
Here's a related SO post for a checklist of potential causes for the problems:
Server clock/time is out of sync
Not authorized for offline access
Throttled by Google
Using expired refresh tokens
User has been inactive for 6 months
Use service worker email instead of client ID
Too many access tokens in short time
Client SDK might be outdated
Incorrect/incomplete refresh token
User has actively revoked access to our app
User has reset/recovered their Google password
Hope this helps!
I have an application that uses Salesforce services using a Remote Access Application. This is working fine so far.
However, my understanding is that even a refresh token will eventually expire, and I believe will return the following as part of a 404 (?):
"error_description":"expired access/refresh token"
My question is this: What is the best practice to test this scenario? I obviously know that the normal refresh token flow is working fine, but how do I appropriately test the negative result?
You can login to the web interface and goto setup -> my personal information. one of the related lists on this page is called remote access, here you can see what refresh tokens have been issues, and revoke any of them.
Go To the Setup and search for the apps
->Go to the connected apps under the managed apps
->select your app, there you can see the edit policies
->click on edit policies -> check for the refresh token policies under OAuth policies