I have a client that is making a getUser SCIM request. It successfully can get an access token and RPT, however when it actually comes to the getUser request, I get a response with the status '403 Forbidden' with a ticket as the body of the response. According to this UMA document a permission ticket indicates the request was valid, but the client does not have permission. I have tried everything I can think of to give this client permissions, but havent managed to get it working.
Does anyone know how to give a client permissions to do SCIM requests?
My current method of attempting a request is:
Get access token using client credentials
Get RPT using access token acquired in step 1 as authorization
make domain.com/identity/seam/resource/restv1/scim/v1/Users request using RPT as authorization
Follow the seek authorization steps of sending request to RPT endpoint with ticket and old RPT. This replies with a new RPT.
Attempt step 3 again using the RPT from step 4 as authorization
Any advice would be appreciated.
Related
I have an api with oauth2.0 authorization grant type authentication which has the following steps -
Get method for authorization code which opens up a form in browser where you need to enter credentials. This results in a series of post redirect requests and finally returns a authorization code in third post response header
Now a post request is sent, with grant type authorization code containing client credentials and the above authorization code we got from the get request, in the body and it returns the access token
This is how it works in postman. How can I achieve the same thing using Rest Assured?
You need two handlers
Handler 1:
To redirect to oauth server. (requeter should identity list of grant types, generate url with client_id and state and redirect application to this url)
Once end user signs in and allows the grant. (assumed that user allows)
Handler 2:
oauth server redirects back to postman with a authorization_code and state.
You need to configure redirect to your server callback url.
Once you receive these two
Verify state is same as what you sent. if yes proceed.
send authorization_code, cleint_secret, client_id back to server to recieve access_token and refresh_token
Use access_token to access data.
Use refresh_token to get new access_token.
I am developing an iPhone application to demonstrate the MFA using sms factor with MFA APIs for POC. I am using the authorisation flow for getting my access token (where I get a authorisation code and redeem it for an access token)earlier to MFA implementation. From the documentation, I found out that I need an MFA_token to work with MFA APIs. I added few changes with my existing authorisation process.
I am getting an MFA Token by doing the following steps:
Added scope enroll read:authenticators to authorisation endpoint( i.e. “https://<my_domain>/authorize”)
Added an audience:
https://<my_domain>/mfa to the authorisation endpoint
Then I make a post request to token endpoint with authorization code to get the mfa_token.
The only changes I can observe is now the access token(which I presume to be the mfa_token) is in jwt format with expire time 600 sec. By using this access token(=mfa_token)
I built a custom pages for my user for enrollment and challenging the user via sms.
I am able to enroll user, confirm enrollment using this access token.
But when I challenge an user using this access token I get the following error after https://YOUR_DOMAIN/mfa/challenge call.
{
“error”: “invalid_grant”,
“error_description”: “Malformed mfa_token”
}
Can anyone please say me where I am going wrong?
Is the access token same as the MFA_Token in my case?
Thanks in Advance!
I think the access_token only serves as mfa_token during OOB/device registration. Thenafter, the user will get an mfa_token during auth, which is passed for MFA/OTP challenges
https://auth0.com/docs/login/mfa/ropg-mfa/manage-authenticator-factors-mfa-api#resource-owner-password-grant
I have set up a Cognito authorizer with an App client that is connected to Google Identity Provider.
"Callback URL" is http://localhost and "Sign out URL" is http://localhost/logout. I have enabled the "Authorization code grant" and the "Implicit grant" flows and the I want to implement the following flow :
User sends a GET request to the LOGIN endpoint (/login) which is the following:
https://mycognAuthorizer.auth.eu-west-1.amazoncognito.com/login?client_id=MYCLIENTID&redirect_uri=http://localhost&response_type=code
User sends a POST request to the TOKEN endpoint (/oauth2/token) with the following parameters
POST https://hocublen.auth.eu-west-1.amazoncognito.com/oauth2/token
Content-Type='application/x-www-form-urlencoded'
grant_type:authorization_code&
client_id:<MYCLIENTID>&
redirect_uri:http://localhost&
code:<CODE_FROM_LOGIN>
Where <CODE_FROM_LOGIN> is the code returned by /login endpoint on the first step.
My problem is that the first endpoint (/login) works fine and I get the code, but the second endpoint always returns a Bad Request response with an "invalid client" message.
Is there something that can be missing from the configuration?
Also, if I choose to ask for a token from the login endpoint instead of a code, is this token equivalent with that of the TOKEN endpoint?
It seems that when one creates an AppClient the "Generate client secret" is enabled by default, but in subsequent views of the AppClient, one has to press show details to see that the password is set and what the password is.
For the scope of my needs, I just removed the password.
Invalid client is occured when you're generating client_secret for your app clients. You should add your client_secret in your request.
I am following this guide (https://learn.microsoft.com/en-us/skype-sdk/ucwa/authenticationusingazuread) in order to access Skype for Business. Everything goes fine till the last part but let's do step by step. I am building my .net console application to do this but in order to explain you properly the problem I am having I will show you directly the http calls through Insomnia (software used to make http calls).
Step 1:
GET request towards https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root
I hit 200 and as answer I receive this:
Step 2:
I use the user link.
So I send an http request to https://webdir1e.online.lync.com/Autodiscover/AutodiscoverService.svc/root/oauth/user and I get a 401 Unauthorized (everything still correct).
In the header of the answer it points me to the Identity Provider to ask for authorization (authorization_uri)
Step 3: I use that link to authorize my app, which has its own client_Id (that I hide in the following screenshot).
This is how I compose the call:
If I send this http request I get redirected to the page where it asks my personal login and by inserting my credentials I succesfully login and hit 404, where in the answer I receive back my access token.
Step 5: I use the access token towards the same AutodiscoverService link of step 1. This is to register my application. I hit 200 and I receive back the link to access Skype for Business.
Finally (and this is where things go wrong) I send a POST request towards the applications link with the Bearer token, and I receive a 403 Forbidden. I think I am following correctly the guide but I can't figure out why I can access the resource at the last step.
EDIT:
The permissions are granted. I hide the name since it contains the name of my company. But it is the same of the domain of my login.
So the token you generated authorizes you to access resources at https://webdir1e.online.lync.com which you've done to fetch a new set of resources including the "application" resouce which is on a DIFFERENT host: https://webpooldb41e14.infra.lync.com.
You actually have to get another OAuth token now which authorizes you for the application resource and then you can POST to that to generate your session in UCWA.
As a side note... If you've defined your own single-tenant application in Azure that has been granted rights to SkypeForBusinessOnline then I think you should be targeting authorization and authentication endpoints of the form:
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token
Also I should add, if you're trying to write a trusted secure client that users in your company will use I would suggest looking up the Resource Owner Password Credentials auth flow. It allows you to directly hit the token endpoint I mentioned above and exchange username/password credentials for an access token. Then you can manage auto-discovery and application creation easily under the hood without getting re-directed back and forth to Azure.
https://learn.microsoft.com/mt-mt/azure/active-directory/develop/v2-oauth-ropc
I'm integrating Okta to my own IdP server by using Okta's API.
I'm implementing the Authorization code flow by following the steps below:
In my own server, use the /api/v1/authn endpoint to get the sessionToken.
Use the sessionToken to obtain the authorization by calling this endpoint: /oauth2/v1/authorize?client_id=" + clientId + "&sessionToken=" + sessionToken + "&response_type=code&response_mode=query&scope=openid&redirect_uri=" + redirectUrl + "&state=evanyang&nonce="
It's supposed to return a response with status code 302 and with the Location header containing the redirect url as well as the code value.
However, I keep getting a response with status code 200 and without the Location header, with a html body saying "You are using an unsupported browser." and "Javascript is disabled on your browser."
According to the API documentation: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request, the sessionToken parameter is sufficient to do this: An Okta one-time sessionToken. This allows an API-based user login flow (rather than Okta login UI).
Am I missing any extra requirement for getting the authorization code through API? Please help.
Thanks in Advance :)
The Authorization Code grant type and the Authorization endpoint in there are meant to be access through a browser, not a non-browser client.
This issue is caused by obtaining session id between obtaining session token and authorization code. Once the session token is used to get session id, it becomes invalid, which means it cannot be used to get authorization code anymore.
According to Okta, the Authorization Code grant type and the Authorization endpoint and be used through a API-based web app too, as long as the session token is provided in the request: http://developer.okta.com/docs/api/resources/oidc.html#authentication-request. In fact, one can use this script(https://github.com/SohaibAjmal/Okta-OpenId-Scripts) to finish the flow.