I hope you are doing fine :)
I have the following problem/problems.
I have created a dummy (robot) user. In Azure AD there is an App Registration with some Power BI delegated permission services.
I want to automate the deletion of a push dataset via a HTTP request.
For this, I need to authenticate against that App Registration from Azure AD. With postman, everything worked perfectly, I got the token as a response.
Then, I tried to make the same request using the HTTP connector in PowerAutomate.
I get the following error
{"error":"invalid_request","error_description":"AADSTS900144: The request body must contain the following parameter: 'grant_type'.\r\nTrace ID: e6d68953-ce1c-4217-856c-ae3aada82e00\r\nCorrelation ID: f50db4d9-d5bb-4396-af11-214717721f43\r\nTimestamp: 2022-10-26 19:12:48Z","error_codes":[900144],"timestamp":"2022-10-26 19:12:48Z","trace_id":"e6d68953-ce1c-4217-856c-ae3aada82e00","correlation_id":"f50db4d9-d5bb-4396-af11-214717721f43","error_uri":"https://login.microsoftonline.com/error?code=900144"}
The connector looks like this->
I have tried other ways as well.
The following error ->
{"error":"invalid_grant","error_description":"AADSTS50126: Error validating credentials due to invalid username or password.\r\nTrace ID: fec65949-0701-4727-af3b-2c2b8eb73a00\r\nCorrelation ID: 42c6c04b-98be-477d-8d36-52a01a473a40\r\nTimestamp: 2022-10-26 19:23:50Z","error_codes":[50126],"timestamp":"2022-10-26 19:23:50Z","trace_id":"fec65949-0701-4727-af3b-2c2b8eb73a00","correlation_id":"42c6c04b-98be-477d-8d36-52a01a473a40","error_uri":"https://login.microsoftonline.com/error?code=50126"}
I get from the the next HTTP connector inputs. I tried creating a query out of the previous json. It says the username or password are invalid but I logged in successfully for a number of times with those exact credentials. That I am sure of.
The dummy inputs in the picture are used to avoid the real ids, username and password.
This worked for me ...
Add a header setting Content-Type to application/x-www-form-urlencoded and add the URL form encoded content string like thus ...
client_id=<CLIENT_ID>c&grant_type=password&username=<USERNAME>&password=<PASSWORD>&scope=User.read
If you're using the password grant type approach, you shouldn't need a client secret, just the client ID.
Related
I'm trying to implement the "on behalf of" flow in an application using ADFS 2016 as STS. As a reference, I look at this Microsoft tutorial (https://learn.microsoft.com/en-ca/windows-server/identity/ad-fs/development/ad-fs-on-behalf-of-authentication-in-windows-server). It's working as it should, I can login into my web application and then use my original access token in UserAssertion to generate a new access token with the proper audience to call my API BUT I found absolutely no way to include any user informations (sub, name, email, upn etc.) into the access token for my API, even if I set claim rules into my ADFS configurations for the API.
I checked the communication between my app and adfs using Fiddler and everything looks like the informations in the tutorial. See the screen shot of the "on behalf of" request below :
Here's the resulting access token :
Finally, here's the code I use to generate my new access token :
private async Task<string> GetAccessToken(ClaimsPrincipal user, string originalAccessToken)
{
var authority = "[authority]";
var context = new AuthenticationContext(authority, false);
string userName = user.FindFirstValue("upn");
var userAssertion = new UserAssertion(originalAccessToken, "urn:ietf:params:oauth:grant-type:jwt-bearer",userName);
var cc = new ClientCredential("https://localhost:44387/", "[client_secret]");
var result = await context.AcquireTokenAsync("https://localhost:44339/", cc, userAssertion);
return result.AccessToken;
}
Have you struggle with that scenario and if yes, did you find a way to fix this ?
Thanks
I've only used the Microsoft On Behalf Of flow with Azure AD and not ADFS, but it looks like you need to send a more detailed scope in your User Info request.
Maybe try sending 'openid profile email', to indicate that you want that type of detail, as in Section 17 of my blog post. Of course this assumes that this type of data has been registered for all users.
TROUBLESHOOTING
Looks like one of these will be the cause:
A suboptimal Microsoft library that does not allow you to send the required scope
Or ADFS 2016 perhaps lacks the scope features that work correctly in Azure AD
I would concentrate on making extra sure you are sending the correct form URL encoded request message, using a tool such as curl, Postman or a plain C# HttpClient. Here is the code I used to send the correct scope - using an open source library rather than a Microsoft one:
Sample NodeJS Code
If you can get the scope sent correctly then you should have a resolution either way:
Either you get the correct data and can update your code
Or the behaviour you want is not supported by ADFS
Good luck ...
I am trying to verify a HS256 JWT Token generated with locally ran KeyCloak Authentication Provider on https://jwt.io.
The KeyCloack instance is running on my local machine inside a docker container. I have applied almost the same steps as described in this answer (which on contrary applies the RS algorithm instead, and works as described): https://stackoverflow.com/a/55002225/1534753
My validation procedure is very simple:
1.) Request the token (with Postman) from my local docker KeyCloak instance with:
POST requesting http://localhost:8080/auth/realms/dev/protocol/openid-connect/token
2.) Copy the token contents inside the jwt.io's "Encoded" section
3.) I verify that the header and payload are as expected and correct
4.) I copy the client secret from my KeyCloak instance admin dashboard, you can see the reference on the image below:
5.) I paste the secret into the "VERIFY SIGNATURE" section on jwt.io and the "Encoded" token section changes, hence resulting with an invalid signature and a invalid (i.e. different) token.
My core question is what am I missing here? Why does the token change when I apply the expected secret!? Am I applying the right secret, the one from the client? If I understand JWT infrastructre and standard correctly then It should stay the same if the secret (with the expected algorithm applied) is valid. My reasoning is that something with JWT creation on KeyCloak is specific. I have not touched the HS256 algorithm provider on KeyCloak, everything is used as default with the docker installation guide on using KeyCloak. The settings related to the token and algorithm are setup to use HS256, and the algorithm is specified as expected in the JWT's header section correctly which can be verified after the encoded token is pasted into the jwt.io's page.
I need this to work as I am trying to apply the same JWT validation process inside a .NET Core web API application. I have encountered this whole issue in there, i.e. inside the System.IdentityModel.Tokens.JWT and the JwtSecurityTokenHandle.ValidateSignature method which results with an invalid signature and finally resulting in an exception.
On side note, I am accessing the token with Postman and its Authorize feature the configuration can be seen on the image below:
One more side note is I have a user "John" which belongs to my "Demo" realm. I use him to request an access token from KeyCloak.
To get the secret used for signing/verifying HS256 tokens, try using the following SQL:
SELECT value FROM component_config CC INNER JOIN component C ON(CC.component_id = C.id) WHERE C.realm_id = '<realm-id-here>' and provider_id = 'hmac-generated' AND CC.name = 'secret';
If you use the resulting secret to verify the tokens, the signature should match. I’m not sure if this secret is available through the UI, probably not.
Source: https://keycloak.discourse.group/t/invalid-signature-with-hs256-token/3228/3
you can try using Keycloak Gatekeeper.
If you want to verify that token in that way you need to change the Client Authenticator to "Signed JWT with client secret", otherwise you can use this "Gatekeeper" option. Here you can read more about it.
We have an instance of Identity Server 3 which has been used for some time with various clients, some using implicit flow, others using client credentials. We now have a new requirement to integrate an iOS native app with this identity provider. I understand these days implicit flow is not recommended and public facing apps should instead be using authorization code flow. Examples of such advice are here and here.
By my understanding, authorization code flow has a step whereby a received authorization code is exchanged for JWT tokens via some back channel by supplying it alongside a client ID and secret. However, with SPAs and native apps we don't have the luxury of storing secrets. The guidance I found here would suggest I can simply omit the secret from the connect/token request, but my testing so far doesn't confirm this. So I'm stuck. To demonstrate, I've set up a client on my local instance of IS3 to test with:
{
'clientId': 'test',
'flow': 'AuthorizationCode',
'name': 'test',
'redirectUris': [ 'http://localhost:8080/' ],
'scopes': ['openid','profile']
}
I then make the following GET request to my IdP:
[ID_PROVIDER]/connect/authorize?client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=openid%20profile&response_type=code
This lets me sign in and returns me to my test app running at http://localhost:8080 with my authorization code in the querystring.
I now try to exchange this code for JWT tokens by POSTing to [ID_PROVIDER]/connect/token with the following body: code=[AUTH_CODE]&grant_type=authorization_code&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080
But Identity Server rejects this with an HTTP 400 and invalid_client error. When I dig into its logs I see a ClientSecretValidator event with message "No client secret found". Which kind of makes sense based on my understanding outlined above, but given people are recommending using this flow for public-facing apps I must be misunderstanding something.
If anyone could clarify that'd be great, thanks.
You can't just omit the client secret. For your native case, I'd consider embedding the secret within the app. The authorize request will still have to validate the return_uri (custom URI scheme for your native app) and if that still feels insecure, you can also lean on Proof of possession (PoP) tokens (https://identityserver.github.io/Documentation/docsv2/pop/overview.html).
For a SPA app I would keep it implicit flow, I see no point in doing secrets there.
I'm trying to setup my Google Identity Toolkit so users can reset their passwords. I'm following the documentation here: https://developers.google.com/identity/toolkit/web/required-endpoints#send_email_url
I'm using the PHP Gitkit Client outlined here: https://github.com/google/identity-toolkit-php-client/blob/master/src/GitkitClient.php
Specifically the function getOobResults() on line 307 seems to be unhappy for some reason. Here's where I'm at:
User sets up account and logs in successfully
User then logs out and starts to log back in, enters email in and clicks "Forgot password"
reCaptcha is shown, click check box and then hit continue
At this point my 'Send Email URL' endpoint (gitkitEmail.php) is successfully called and the following POST is set to it (dropping the full '&response' param since it goes on for a while):
action=resetPassword&email=xodfebefa%40nada.ltd&challenge&response=03ACgFB9tGlNt2KAGhrVY....
I then take that string and parse it using parse_str(); since getOobResults() is looking for an array. However, response I get back is always:
{
"response_body": {
"error": "CAPTCHA_CHECK_FAILED"
}
}
I searched around but can't find any details on this error. Any help would be appreciated. I don't have a reCaptcha setup anywhere on my site, unsure if this is expecting me to do that and that's why it's failing? Also, I did bump all my code to a production environment and got the same error there as I did on my localhost.
I can't get my refresh token with my code. I can only get my access token, token type etc.,
I have followed some tutorials like putting access_type=offline on my login URL:
echo "<a href='https://accounts.google.com/o/oauth2/auth?"
. "access_type=offline&client_id=123345555.apps.googleusercontent.com& "
. "scope=https://www.googleapis.com/auth/calendar+https://www.googleapis.com/auth/plus.me&response_type=code& "
. "redirect_uri=http://www.sample.com/sample.php&state=/profile'>Google</a>";
and my fields in getting the access token:
$fields=array(
'code'=> urlencode($authcode),
'client_id'=> urlencode($clientid),
'client_secret'=> urlencode($clientsecret),
'redirect_uri'=> urlencode($redirecturi),
'grant_type'=> 'authorization_code',
);
but I can't get refresh_token, just the access_token, token_type, id_token and expires_in.
Found out by adding this to your url parameters
approval_prompt=force
Update:
Use access_type=offline&prompt=consent instead.
approval_prompt=force no longer works
https://github.com/googleapis/oauth2client/issues/453
If I may expand on user987361's answer:
From the offline access portion of the OAuth2.0 docs:
When your application receives a refresh token, it is
important to store that refresh token for future use. If your
application loses the refresh token, it will have to re-prompt the
user for consent before obtaining another refresh token. If you need
to re-prompt the user for consent, include the approval_prompt
parameter in the authorization code request, and set the value to
force.
So, when you have already granted access, subsequent requests for a grant_type of authorization_code will not return the refresh_token, even if access_type was set to offline in the query string of the consent page.
As stated in the quote above, in order to obtain a new refresh_token after already receiving one, you will need to send your user back through the prompt, which you can do by setting approval_prompt to force.
Cheers,
PS This change was announced in a blog post as well.
It is access_type=offline that you want.
This will return the refresh token the first time the user authorises the app. Subsequent calls do not force you to re-approve the app (approval_prompt=force).
See further detail:
https://developers.google.com/accounts/docs/OAuth2WebServer#offline
This is complete code in PHP using google official SDK
$client = new Google_Client();
## some need parameter
$client->setApplicationName('your application name');
$client->setClientId('****************');
$client->setClientSecret('************');
$client->setRedirectUri('http://your.website.tld/complete/url2redirect');
$client->setScopes('https://www.googleapis.com/auth/userinfo.email');
## these two lines is important to get refresh token from google api
$client->setAccessType('offline');
$client->setApprovalPrompt('force'); # this line is important when you revoke permission from your app, it will prompt google approval dialogue box forcefully to user to grant offline access
For our app we had to use both these parameters access_type=offline&prompt=consent.
approval_prompt=force did not work for us
Hi I followed following steps and I had been able to get the refresh token.
Authorization flow has two steps.
Is to obtain the authorization code using https://accounts.google.com/o/oauth2/auth? URL.
For that a post request is sent providing following parameters. 'scope=' + SCOPE + '&client_id=' + CLIENTID + '&redirect_uri=' + REDIRECT + '&response_type=' + TYPE + '&access_type=offline' Providing above will receive a authorization code.
Retrieving AcessToken and RefreshToken using https://accounts.google.com/o/oauth2/token? URL.
For that a post request is sent providing following parameters.
"code" : code,
"client_id" : CID,
"client_secret" : CSECRET,
"redirect_uri" : REDIRECT,
"grant_type" : "authorization_code",
So in your first attempt once you authorize the permissions you will be able to get the Refresh token. Subsequent attempts will not provide the refresh token. If you want the token again the revoke the access in you application.
Hope this will help someone cheers :)
OAuth has two scenarios in real mode.
The normal and default style of access is called online.
In some cases, your application may need to access a Google API when the user is not present，It's offline scenarios .
a refresh token is obtained in offline scenarios during the first authorization code exchange.
So you can get refersh_token is some scenarios ,not all.
you can have the content in https://developers.google.com/identity/protocols/OAuth2WebServer#offline
.
Since March 2016, use prompt=consent to regenerate Google API refresh token.
As mentioned in https://github.com/googleapis/oauth2client/issues/453,
approval_prompt=force has been replaced with prompt=none|consent|select_account
For those using the Google API Client Library for PHP and seeking offline access and refresh tokens beware as of the time of this writing the docs are showing incorrect examples.
currently it's showing:
$client = new Google_Client();
$client->setAuthConfig('client_secret.json');
$client->addScope(Google_Service_Drive::DRIVE_METADATA_READONLY);
$client->setRedirectUri('http://' . $_SERVER['HTTP_HOST'] . '/oauth2callback.php');
// offline access will give you both an access and refresh token so that
// your app can refresh the access token without user interaction.
$client->setAccessType('offline');
// Using "consent" ensures that your application always receives a refresh token.
// If you are not using offline access, you can omit this.
$client->setApprovalPrompt("consent");
$client->setIncludeGrantedScopes(true); // incremental auth
source: https://developers.google.com/identity/protocols/OAuth2WebServer#offline
All of this works great - except ONE piece
$client->setApprovalPrompt("consent");
After a bit of reasoning I changed this line to the following and EVERYTHING WORKED
$client->setPrompt("consent");
It makes sense since using the HTTP requests it was changed from approval_prompt=force to prompt=consent. So changing the setter method from setApprovalPrompt to setPrompt follows natural convention - BUT IT'S NOT IN THE DOCS!!! That I found at least.