I am developing a web application that allows any user to connect with its Salesforce account. I've implemented User-Agent Flow and I obtain correctly access_token and other info but I can't obtain refresh_token, even if I have the correct scopes (api, web, refresh_token, offline_access).
This is the request I use:
https://login.salesforce.com/services/oauth2/authorize?response_type=token&scope=refresh_token&client_id=[MY_CLIENT_ID]&redirect_uri=[MY_REDIRECT_URL]
And my redirect URL is:
http://[MYSITE].com/#/services/oauth2/success
(that corresponds to the host from where I make the call)
This call correctly gives me access_token but not refresh_token.
if I use "https" instead "http" as redirect uri I receive this error:
error=invalid_scope&error_description=the requested scope is not available
From the documentation, I read that:
The refresh token for the user-agent flow is only issued if you
requested scope=refresh_token and one of the following scenarios is
true:
....
The redirect URL host matches the request host and includes the servlet services/oauth2/success.
...
I think to be in this case, what am I doing wrong?
Thanks in advance
Try adding Perform requests at any time (refresh_token, offline_access) under Selected OAuth Scopes in your connected app
Related
As we can see here: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par#section-2.2
pushed authorization request lifetime should be between 5 and 600 seconds.
So assume that it's 60 seconds. Then client redirects user to authorization endpoint and... user is not logged in. So authorization endpoint redirect the user to endpoint with login page with request_uri as query param. The user logs in, login page redirect user to authorization endpoint with request_uri from query param. Probably, if lifetime was about 10s the request_uri is expired now (and what's more it's used more than once). So how can we handle the flow when user is not authenticated while he is redirected to authorization endpoint and we use PAR?
I know that can be 600 seconds also, but the recommendations say that this lifetime should be as short as possible. Therefore, it seems to me that I misunderstand how PAR works. I don't think even 10 minutes is enough because what if user currently doesn't have account at the identity provider or there is MFA used?
Please tell me, how PAR really works.
Consider a browser based app implementing this flow:
STEP 1
The browser wants to begin a login and calls its backend. The backend sends a standard Open ID Connect request like this to the authorization server:
POST https://login.example.com/oauth/authorize/par
Authorization: Basic czZCaFo3RmpmcDBa:QnIxS3REUmJuZbUl3
client_id=myclient&
redirect_uri=http%3A%2F%2Fwww.example.com%2F&
scope=openid%20profile&
response_type=code&
response_mode=jwt&
code_challenge=WQ4Y4CQpO8W6VtELopzYHdNg&
code_challenge_method=S256&
state=NFBljlVuB1GDjgGARmqDcxtHhV8
The authorization server saves the OIDC request details. Note also that the authorization header includes the client secret, which is one of the key features of PAR - the client authenticates before the redirect to the authorization server. So a malicious app cannot redirect a user with your client ID, since they do not know the secret.
STEP 2
The browser then uses the request URI. The short time you mention is only for this redirect and does not impact user login time:
https://login.example.com/oauth/authorize?
client_id=myclient&
request_uri=urn:ietf:params:oauth:request_uri:7d353fc8-9b94-488f-8c61-cf7cc1dfef9e"
STEP 3
The user logs in, and in some cases that might take a minute or so, as you say. Then a response is returned to the browser:
https://www.example.com/callback?response=eyJra...
In this example I am receiving the response as a JWT, using a related standard called JARM that can be used in conjunction with PAR. The JWT looks like this and could contain an error response in some cases:
{
"exp": 1629112321,
"iss": "https://login.example.com",
"aud": "myclient",
"iat": 1629112301,
"purpose": "authz_response",
"code": "abcdef",
"state": "12345abcdef"
}
If you don't use JARM you will instead receive code, state and error fields in the browser URL. The flow finishes with the usual authorization code grant POST, to swap the code for tokens.
SUMMARY
All of the above is designed to prevent man in the browser attacks. Eg a malicious party cannot alter any fields in flight. Extra security is therefore added to the standard code flow.
I am trying to configure a third party web application to use Azure AD as the OIDC provider. The authentication works fine, however I am looking for some claims and not able to find an ID or Access Token. Here is the flow as I am seeing it
Call to the login page of the web application. This gets a 302 redirect to the Microsoft OAuth endpoint as below
The URL is https://login.microsoftonline.com/-tenantid-/oauth2/v2.0/authorize?client_id=-clientid-&redirect_uri=-encodedCallbackURI-&response_type=code&scope=openid+email+profile&state=123 This does a 302 to below URL
Next call is to https://login.microsoftonline.com/-tenantid-/oauth2/v2.0/authorize?client_id=-clientid-&redirect_uri=-encodedCallbackURI-&response_type=code&scope=openid+email+profile&state=123&**sso_nonce=O.eyJ0eXAiOiJK......**&client-request-id=-guid-&mscrid=-guid- This returns a 200
Next is the redirect back to the hosted web application indicated in teh callback - https://webApplicationURL/callback?code=0.AQ4Ayjxg80......&state=123&session_state=5b7c2e43-9eab-4bb1-9f24-d020f144d30d
At this point, the user has successfully been authenticated. However, I would like to find the ID or Access Token received.
The sso_nonce(in #3) is in a JWT format but has no claims.
The code(in #4) doesn't have any of the claims either and doesnt really seem to be a JWT token format.
So where is the ID Token or Access Token that I can use to decode and see what claims are getting passed (or not)?
Thanks in advance,
Jake.
To get tokens while calling login page of the web application, you can execute the below request in browser by including response_type as id_token+token:
https://login.microsoftonline.com/<tenant_ID>/oauth2/v2.0/authorize?
client_id=da5daf42-xxxx-xxxx-xxxxxx04a52 //your AppID
&response_type=id_token+token //Required
&redirect_uri=https://jwt.ms //your Redirect URL
&response_mode=fragment
&scope=openid+profile+email
&state=12345
&nonce=678910
Make sure to enable tokens for your web application before executing the above request like below:
Go to Azure Active Directory -> App Registrations -> Your App -> Authentication -> Enable tokens -> Save
I tried to reproduce the same in my environment and got the below results:
When I executed the above-mentioned request in the browser, it asked me to sign in like below:
After successful sign-in, it took me to the redirect URL with tokens in the address bar like below:
When you copy-paste the above in Notepad or any, you can find both access_token and id_token like this:
I got the claims successfully when I decoded the token like below:
Reference:
OpenID Connect (OIDC) | Microsoft Docs
I have setup an App in Azure Ad for Oauth 2.0 using JWT, the access token is returned successfully but the url has a hashtag(#)between the redirect URL and the access_token. Application is expecting a question mark(?) to complete the sign, so if I replace the # with ? on the address bar the sign-process completes.
Is there a way to do this from Azure App Registration itself so that the response is returned with a ? instead of #? or should I be sending the request differently?
Below is the request
https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?client_id=<client_id>&response_type=token&redirect_uri=<url_encoded_redirect_uri>&scope=<scope>&response_mode=fragment&state=12345&nonce=678910
In the request, response_mode had to be form_post instead of fragment. That solved the issue
https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize?client_id=<client_id>&response_type=token&redirect_uri=<url_encoded_redirect_uri>&scope=<scope>&response_mode=form_post&state=12345&nonce=678910
Reference - https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#send-the-sign-in-request
I have a hobby project in mind to use battle.net login. I'm wondering how I can obtain the access token from the API after receiving the authorization code.
This is Oauth flow question rather than a battle.net question.
Currently I can successfully authorize the user for my app which is registered in dev.battle.net and then I try to use the authorization code returned from the battle.net login to obtain the access token by sending a request to https://<region>.battle.net/oauth/token.
However I keep receiving this error:
{
"error": "unauthorized",
"error_description": "An Authentication object was not found in the SecurityContext"
}
I use postman extension to send post requests to that uri. I authenticate my request with my client id and secret. I pass redirect_uri (https://localhost), granty_type (authorization_code), code(the code returned from the previous authorization step). However I keep getting the error above.
I couldn't find much about battle.net online. There are other oauth related help articles but couldn't really find my way.
Wondering if you can help me with this easy stuff. I'm just wondering what I'm skipping here.
Here is the documentation:
https://dev.battle.net/docs/read/oauth
https://localhost is added in my mashery dev account's app settings.
Me again, I resolved this problem after trying almost every combination in the universe:)
Steps to apply:
Don't use the same authorization token for different access token trials, they are not valid
Always use https on every domain you test including localhost, you
redirect_uri must be https as well.
You must use the "basic authentication" in the header of your POST request while requesting the token from the authorization code you obtained from the previous step.
This is one of the most important ones: For requesting token, Pass redirect_uri, client key and secret as POST form parameters to the authenticated request. This is interesting because it's already an authenticated request; why would i need to pass my secret again? Anyways, that's how it works.
Here are the full text:
http://hakanu.net/oauth/2017/01/26/complete-guide-of-battle-net-oauth-api-and-login-button/
This is working prototype:
https://owmatch.me
Thanks.
I was wondering why we need to specify the redirect uri both in our code and in google developer console when using Oauth2.I was following this tutorial http://www.tothenew.com/blog/grails-way-of-oauth-2-0-to-access-google-apis-part-1/.
The client may register multiple redirect_uri's with the Authorization Server (i.e. Google) and sending the redirect_uri in the request itself is to let the Authorization Sever know on which one of the registered redirect_uri's the client wants to receive the authorization response.
The redirect_uri parameter is optional by spec: if there's only one registered, then the redirect_uri parameter may be omitted from the request.
The only redirect URI which really matters is the one which you enter into your Google Developer Console. This redirect URI is what Google will use to reconnect with your web application after it has either approved or rejected your authorization attempt.
The reason you are also specifying this redirect URL in your code is to ensure that your application can correctly recognize the incoming redirect request.