Me and my team are developing an API to secure files,in that API we need Onedrive(cloud storage).we integrated Onedrive using MicrosoftGraph authentication as shown in the below link.
enter link description here
The thing is when i try to authenticate and sign in to pesonal account it works but for organisation account i'm facing the issue as shown in the below
We have recieved a bad request.****(AADSTS165000: Invalid Request: The request tokens do not match the user context. Do not copy the user context values (cookies; form fields; headers) between different requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token values do not match;])****
pls help me technically.
Your token does not match the user context. This is because although you are logged in to your organization account, the token you use is still issued by your personal account.
The access token is unique. If you need to log in with an organization account, then you must set the organization account as the token issuer. You need to log in with your organization account to obtain a new authorization code, and then use the authorization code to obtain the token again.
Related
I'm a bit of a salesforce / web noob, but am testing out the customer 360 external identity licences, along with customer users. My main goal is to authenticate a customer user using OAUTH, get an access token, then use the Salesforce web APIs to access some relevant bits of info for the customer user. However I just can't seem to figure out how to get the customer user authenticated despite being able to do the same just fine for my personal admin user account.
I have the following setup:
a bunch of external identity licences
a profile with the external identity user licence assigned, with the API enabled setting checked.
a connected app setup with relaxed IP restrictions set, all users may self authorize set, OAUTH settings enabled, device flow enabled, and the full access OAUTH scope selected.
an end customer contact with an associated end-customer user, assigned to the external identity profile and thus external identity user licence.
And I'm POSTing to the test token endpoint (https://test.salesforce.com/services/oauth2/token).
I've tried two auth flows, password and device flow for IOT as I want to integrate this with a command line app (which the IOT flow is good for apparently), and while both succeed for my personal salesforce user credentials, they both fail for my test user account credentials.
The server response for the password flow is as follows:
{
"error": "invalid_grant",
"error_description": "authentication failure"
}
End-customer users don't appear to have a security token so I've just been using the password on its own. I can't seem to find a way to generate a security token for these types of users but suspect this could be the issue for this flow.
When trying the device flow the returned verification uri is always https://test.salesforce.com/setup/connect but attempting to login on this page as the customer-user fails with this error:
Please check your username and password. If you still can't log in, contact your Salesforce administrator".
I am definitely providing the correct customer user credentials here so have no idea why this fails.
Does anyone have any ideas on how to get this working?
#eyescream nudged me in the right direction so here's the solution for anyone in the same position as me.
Authentication of external identity customer users is not done using the normal OAUTH REST endpoints (https://test.salesforce.com/services/oauth2/token or https://login.salesforce.com/services/oauth2/token).
Instead you have to setup an experience cloud site, add your customer user profile to the sites list of member profiles, then authenticate using a site specific AUTH endpoint.
For example, if your experience cloud URL is https://sandboxname-companyname.instanceid.force.com, then your OAUTH token endpoint would be at:
https://sandboxname-companyname.instanceid.force.com/services/oauth2/token
Extra things to note:
customer user accounts cannot authenticate using the username-password flow.
the device flow for IOT (or command line apps) will return a verification URL that customer users cannot log in to (https://test.salesforce.com/setup/connect). You can instead use the experience site connect URL (https://sandboxname-companyname.instanceid.force.com/sitename/setup/connect)
Currently I have this setup:
At login, and in every subsequent request after login, a mobile application that I have built uses Basic Authentication to authenticate the user with a web service that serves the app with information it requests.
On every request the Authorization header is inspected, the password and username are extracted from the header, the password is hashed using a proprietary DLL (so the web service doesn't actually contain the hashing algorithm) and compared to the hashed password associated with the username that is stored in the database.
I have now been asked to include Azure AD SSO in the login options.
After reading much about the topic, this looks seems to me like the setup:
I'm curious about a few things:
Is this setup correct, more or less?
Does the app send the Identity Token to the web service? If so, how does the webservice validate that token?
Is it correct that the webservice can match the Azure Identity to the DB user using one of the claims in the Security Token?
Where do Access Token fit in this picture?
Thanks for the help!
(Side Note: I know that Basic Authentication is not the preferred way to go in the first scenario. This was a temporary decision till we developed the token handling code, it only works using HTTPS and this is an internal application - you wouldn't be able to activate the app unless you have a code we give you)
I have little experience in azure ad but I think we could talk about your case.
First, whatever id token and access token are both jwt token, so to your web service application, you need to use jwt decode library to decrypt the token and get claims it contains. Here we need to know the difference between id token and access token, and I think you'll know that for your web service application, if it's more likely to play the role of an api application, you need to use access token because this token also contains user information. Then you need to add code in your program to decode the token and check if it's a 'valid' token for the request.(Because you've used azure ad to achieve the login part, you don't need to use your custom login part.)
Next, the signing in feature provided by azure ad requires to use account and password in the tenant which azure ad belongs to, the user accounts may look like xx#xx.onmicrosoft.com, it doesn't required to keep sycn with the accounts in your database, so it's difficult and needless for you to compare the user name obtained from the decoded token with those in your database. Because when your web service received the token(id or access token), that means someone has passed the authentication from azure ad. The token contains user information including role, expired time etc. You need to check if the token has expired and if has the correct scope. (Let's see a common situation, microsoft provides many graph apis to call, when accessing these api, we need to provide access token in request head with matching scope, e.g. https://graph.microsoft.com/v1.0/me
requires a delegated api permission of User.Read)
To sum up here, if your web service just required the users in your database to sign in then can be access, id token and access token are both suitable for you because they both contains user name like 'xx#xx.onmicrosoft.com', what you need to do is decode the token and check if the token has expired and whether this user exists in your database(you may set up a mapping between them).
After users sign in, grant permission, and redirect back to my app. I got something like this
{"state"=>"xxx",
"code"=>"yyyy",
"id_token"=>"zzzz",
"user"=>"{
....
}"}
Which is everything I need to create a user account, but the OAuth flow isn't finished yet. For a normal flow, we would use that code to fetch access token from https://appleid.apple.com/auth/token
https://developer.apple.com/documentation/signinwithapplerestapi/generate_and_validate_tokens
My question is, should I do that? It seems to add no value to the current situation.
Basically generate_and_validate_tokens is only if you are using web-based login. If you are using Authenticationservices, then framework handles all the authorisation logic for us. Hence fetching access token from https://appleid.apple.com/auth/token is not required.
Apple is returning id_token directly after user authorization in the call-back response if you request for it, which seems to be your case as well. If you just need users identity to create an account or sign in the user to an associated account on your side, you do not need to fetch access/refresh token by exchange code against the /token api. Just make sure to validate the id_token as mentioned in Verify the Identity token before getting the user details from it.
Exchange of authorization code for access/refresh/ID token will be necessary if you do not request id_token in the initial authorization request and you need users identity to proceed. You can then fetch it as per Retrieve the User’s Information from Apple ID Servers
I'm developing an integration with LinkedIn for my company, and I'm noticing this behavior when switching between different development environments:
I have an active LinkedIn account on EnvA
I authorize the same LinkedIn account on EnvB
The account on EnvA is immediately denied on all API requests with an error of "Unable to verify access token"
So it seems like there can only be one active access token per LinkedIn user at one time? Is it correct behavior for an existing access token to become invalid upon generation of a new one, even if the other access token is on a different domain?
Thanks,
Matt
Requesting a new access token for a user invalidates any existing tokens. You can only have one functional token per app per user at a time.
I have an application that currently integrates into my merchant account using my access token. Early discussion with neighborhood merchants indicates some positive interest. I want to integrate OAuth support so that I can try to get traction with those merchants.
Though https://docs.connect.squareup.com/api/connect/v1/#navsection-oauth has information, I seek some additional clarification.
(i) Access using https redirect-url is denied at Square Connect Authorize has an answer "By default the OAuth flow is disabled for applications which is why you are seeing the "Authorization not allowed" failure. If you wish to enable OAuth flow for your application then you need to contact Square." #SquareConnectSupport: I have sent an email to Developer#Square, please let me know what else do I do.
(ii) Here is how I think it will work - the OAuth integration (Please confirm)
User types in browser say "mysnow.com/square"
The Handler at "mysnow.com/square" allows user to type in an ID this ID is local to mysnow
Then the Handler at "mysnow.com/square" directs the merchant to https://connect.squareup.com/oauth2/authorize along with my application id, permissions and redirect url.
The handler then receives a notification code with AuthZ Code at the redirect URL previously provided.
Next the handler obtains the Access token (using the AuthZ code)
Finally, the handler then saves the ID, the AuthZ code , the relevant Access Token and the date/time stamp (when the token was obtained) as a tuple in a safe data store.
(iii) Using the Access Token
When there is need to access merchant data of given ID, then use the ID to get the Access Token. Use this Access Token to manage the permitted data (based on permission)
Renew the access token periodically.
(iv) For testing purposes, I create few test/dummy merchants? Or do you have dummy merchant accounts that I can use for testing.
You can authorize up to ten merchants through the OAuth flow without approval from Square, which should be enough to get your integration running and tested. If you would like to make it more broadly available, you will need to contact Square about getting the app in the Square App Marketplace.
That looks essentially correct. The best practice for OAuth is something like this:
Merchant visits your landing page (e.g. mysnow.com/square) and clicks an action to start using your square integration.
Merchant's browser is redirected to the OAuth page (https://squareup.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&scope=LIST_OF_OAUTH_SCOPES_YOU_NEED)
Merchant authorizes your application to access their data and is redirected back to your site. In the URL is an authorization code
Your backend makes an API call to Square to exchange the authorization code for an access token. It then uses that access token to look up information about the merchant and pre-populate fields of your signup form (e.g. you can get name, email, etc)
With a partially populated signup form on your site, merchant is prompted to complete their registration with your service.
There isn't really a way to create "dummy" merchants, but you can sign up for multiple merchant accounts with the same identity information, as long as you use a different email for each one. If you have GMail, you can do "you+someword#gmail.com" and the mail will be redirected to "you#gmail.com", so you don't need to create a bunch of email accounts to have unique email addresses.