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
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 am configuring an Azure app service to use the built in Authentication (EasyAuth) it seems to be working well with no auth code written at all. I am able to get the id and access tokens from the headers as expected.
What I am wondering now is what type of validation I should be doing on those tokens within the app to be sure they are legit. I understand the auth layer placed infront the of the app takes care of this, but I am concerned that if that auth is ever mistakenly disabled the app will be wide open.
It appears I might be able to POST the id_token from the x-ms-token-aad-id-token header to https://{sitename}/.auth/login/aad and this will validate that the token is legit? Is this a good and simple way to double check auth was done properly?
You may use the below link to understand the details.
Tutorial: Authenticate users E2E - Azure App Service | Microsoft Learn
I have an implementation of IdentityServer4 which connects with Azure AD for authentication (OIDC). In the callback method, using the IdentityServertools, I am generating the access_token and redirecting the user to SPA with the same. The SPA then stores the access_token into localstorage and uses it for authentication.
Normally, when my SPA app hits the token endpoint of the IdentityServer4, it gives access_token and refresh_token and then uses refresh_token to re-authenticate a returning user.
In this case of SSO with Azure AD, do I need to generate refresh_token manually? If yes, I can build on top of default implementation and that's not the problem (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
My real question is, is there a need of refresh_token here? Because refresh_tokens are stored in DB and never get's deleted and after sometime, these refresh_tokens table will swell (right now it already has 80k rows). The user is expected to click on a small tile inside SAP's Successfactor - that will open the signin/consent screen of Azure or will directly take the user to the main page where zhe will just answer a question and done. So it's hardly 2-3 mins business. So I can continue to generate access_tokens from my IdentityServer4 for every click as I don't expect the user to stay authenticated in the browser if zhe has logged out from SAP's Successfactor (or any other app linked with Azure).
Please advise, if I should generate refresh_token? Is it a good architecture?
Access token is used to prove the request is allowed to access the resource(such as api from ms or your custom api) and refresh token is used to refresh access token to make sure the access token isn't expired. Access token will expire in an hour by default and refresh token has 90 days.
At this point, we can easily find the refresh token is designed for some special scenarios because the expired time for refresh token is much longer than access token's expired time, but we can also generate a new access token in other way such as using msal or sign in again.
As you said in the question, you can generate an access token by one click and you don't expect users to stay authenticated for a long time. So I think it's unnecessary for you to use refresh token.
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
for various business reasons our login progress is basically a workflow composed out of a variable number of steps (where the ID provider login - ie google, facebook etc ) is only a very small part of the entire workflow.
we have an identity server instance set up for various 3rd party integrations (using the client credentials flow).
we have a current new requirement to expose an oauth version of our authentication flows.
i'm wondering if this is somehow supported?
in essence use identity server to validate the client and it's return url and the like - but keeping the actual act of login completely seperate.
if not - I'm guessing that we should self validate client and return url - using a custom grant to return access & refresh tokens to the 3rd party.
IdentityServer and "login application" can be separate. Unfortunately we don't have good documentation for that.
But the specs are basically
Configure the login page URL on the options in startup
We hand you a return URL to the login page
When you are done, call a custom API in the IdentityServer app that sets the sign-in cookie
redirect back to the return URL you got in the first place
As I said, right now you are pretty much on your own. But it has been done before - if you get it working, feel free to contribute that back to the docs.