Calling Microsoft Graph API results with OrganizationFromTenantGuidNotFound - microsoft-graph-api

I'm trying to use this sample code https://github.com/microsoftgraph/aspnet-snippets-sample to talk to GraphAPI but when request is being sent I'm just getting OrganizationFromTenantGuidNotFound (in an exception 401 unauthorized).
I went through readme, step by step, and recheck already dozens of times to make sure that clientId, tenantId, secret are valid. Even decoded JWT token to make sure that's valid.
Googling it doesn't really helped. Does anyone have may have an idea what's changed to GraphAPI since this sample code have been provided?
I'm using currently Azure 30-days free plan.
App registration permissions given:
Cheers

In scenarios where you are working with Office 365 and exchange, your app needs to be registered in the same AD as your exchange or Office365.As Jason rightly pointed out, please try out in an account with the said privileges' and provide your feedback.

Related

Getting invalid authorization_code, error AADSTS70000: The provided value for the 'code' parameter is not valid. The code has expired

I'm using an Office 365 Family account, and getting an incorrect authorization code back, using the following url:
'https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=[CLIENT ID]&response_type=code&redirect_uri=[REDIRECT URI]&response_mode=query&scope=offline_access%20Calendars.ReadWrite%20Files.ReadWrite.All%20User.Read%20openid%20profile&state=12345';
The code I received on one attempt was: M.R3_BAY.44e411b5-8fcf-f0be-2356-d56fd3293055, and they all have that format whenever I try, which is not what it should be like, and does not decode on jwt.
Can anyone please tell me what's going wrong? I've been searching for months for an answer without any luck.
If this is the authorization code, it is not meant to be decoded.
You are supposed to exchange it for tokens, which are in JWT format.
Documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow#request-an-access-token
If this is in fact an access token, it could be for a personal Microsoft account. I've seen different format tokens there before.
You currently allow all Office 365 accounts and personal Microsoft accounts since you use common endpoint on v2.0.
If you only mean to support all Office 365 accounts, you can use organizations instead.

Discord API - random "invalid code" error passing back generated OAuth2 code

I've successfully implemented Discord's OAuth2 flow using the authorization code grant type into my application. The end user navigates to Discord's OAuth2 link for my bot, authorizes its access, and Discord redirects them back to my site with a code querystring. The bot then exchanges this code for an access token by querying Discord's API. Documentation on this process is available here for reference.
However, roughly every 50-100 requests to the exchange endpoint, I receive a 403 with the error invalid_grant and the description Invalid "code" in request. Frankly, I don't understand how the code just provided by Discord's system is instantly invalid. The same user can complete the process again and no error is returned the second time.
Out of desperation, I tried toggling on the option in the Developers Dashboard named Requires OAuth2 Code Grant seeing that it said "if your application requires multiple scopes," but it made no effect. I've also tried endless debugging, but the circumstances under each occurrence are apparently random. Oddly enough, I can't find anyone with the same issue online.
Below is the request I'm making in Node.js using the superagent library. It matches the documentation and works perfectly, other than the response randomly being the error described.
superagent.post('https://discordapp.com/api/v6/oauth2/token')
.type('x-www-form-urlencoded')
.set('Content-Type', 'application/x-www-form-urlencoded')
.send({
client_id: process.env.BOT_ID,
client_secret: process.env.BOT_SECRET,
grant_type: 'authorization_code',
code,
redirect_uri: process.env.OAUTH2_REDIRECT_URI,
scope: 'identify guilds.join',
});
I can confirm that all variables match their expected values. The value of redirect_uri matches that of redirect_uri in the original URL used. code is the value of the code querystring returned through the OAuth2 flow.
What (if anything) am I doing wrong that's causing the error?
Update 1:
Discord has directed me to the API GitHub repo, and I found the issue closed here. Commented and will update here if I receive any helpful info or resolve the issue completely (hopefully the case).
Ran into the same issue using nodejs. Leaving here notes for prosperity:
On Node, if there is no explicit app.head() handler, the .post() handler receives all head requests
Several Android phones, upon being redirected from discord, first send a head request to the endpoint
Meaning:
The user authenticates on discord, then through the redirect back, does a head request. This pulls discord with the code, BUT directly afterwards it also does a post request, which will fail (as you already used the code once), and possibly un-authenticates the user.
Solution for my specific issue was an explicit .head handler for all callback endpoints, which basically just returned the same headers (a redirect) as the post one did, but without calling discord.
Hope this helps.
did you use the OAuth2 link to invite your bot to your server - with the correct permissions? If so, in your main.js file did you define the token?
I.e. bot.login(“YOUR_TOKEN_HERE”)
I would recommend not toggling the ‘Requires OAuth2 Code Grant’ as it is a pain to do anything with in the beginning.
Please let me know of any progress :)

Asana API Personal Access Token return 401 (Unauthorized)

When we are accessing Asana API we are using the Asana node client v0.15.0 together with an Tampermonkey script. The Api is responding with an 401 (Unauthorized).
This worked a couple a days ago. I have tried with new Personal Access Tokens but still get the same error.
While fiddling the request I tried to change the auth-header Bearer to be lower cased.
Authorization: Bearer my-personal-access-token ->
Authorization: bearer my-personal-access-token.
This seems to work fine, that indicates that something changed on Asana's side.
The node-asana js client lib does not let me modify the request before sending it to Asana API.
According to Asana API support it is on stackoverflow that I should ask about help on this matter.
EDIT
By some further investigation it seems that when we send in the cookie
auth_token=My auth token we do get the 401 error. But If removing the cookie and reissue the request in fiddler it works fine.
Another note is that now we do not get any custom_fields in the response from e.g https://app.asana.com/api/1.0/tasks/TaskId
I'm a Developer Advocate at Asana. You've caught something that is a known issue and we're working on a fix :) We're rolling out a new version of our API. It's intended to be backwards-compatible with the older implementation, but giving us multiple forms of authentication is one of those cases where we do something different between the two.
For security purposes, we initially implemented this in the new version to not allow requests with multiple forms of authentication, but it turns out that in-browser integrations were affected in precisely the way you're seeing: being logged into Asana, which causes your browser to send your authorization credentials for requests to asana.com automatically, and also authorizing "the right way" for our API with OAuth or a Personal Access Token will end up breaking. We're working on a fix that will allow this to work for the case when both the logged in (cookie) user and the API (access token) user are the same.
If this is an urgent issue and you want to force the old behavior to happen while we roll out the fix in our newer API implementation, you can set a header as described in that link --^ to force your requests on to the old API. Once we get the new API fully deployed and stable, though, we'll deprecate that header, so please be cautious in relying on it for a long-term solution.
Sorry that this has caused issues for you, and thanks for creating this question to let us know!

MVC google login - OpenID auth request contains an unregistered domain

When I try to login today via google in my web app, I get that error:
400 That’s an error.
OpenID auth request contains an unregistered domain:
http://XXX.XXX.XXX/ (IP here)
But on localhost everything works fine. What is more - on other project also everything works nice.
I'm using default OAuth:
OAuthWebSecurity.RegisterGoogleClient();
How to resolve it?
I would like to add some context to this thread together with a potential solution to developers that are currently blocked.
Back in February we announced the deprecation of OpenID 2.0 (OID2) scheduled for April 2015. We also announced that new OID2 relying parties (RPs) registrations** will no longer be accepted after April 2014.
Given that the API will be shut-down in less than a year’s time, our intention is to avoid having new RPs integrating with Google's OID2 API. Instead, we suggest to use our OpenID Connect API which we consider more secure and easier to implement.
Registrations were effectively closed on May 19th (as documented in the Google’s OID2 developer documentation). All RPs already using OID2 should not be affected by this the closure.
As for developers currently working on an integration with our OID2 API (presumably because they missed the announcement and warnings in our OID2 documentation), we will do our best to minimize the friction caused by the registration closure. If you are in such situation, please let us know by posting a registration request before June 15th. The post should contain a sample OID2 request used by your application, in case you prefer not to disclose such information, please post an email address and we will reach out. We plan to look into each case and try to get you unblocked in the best possible way.
Miguel.
** OID2 does not have a registration procedure for RPs integrating with an identity provider. RPs are associated to the realm value (e.g., www.example.com) used when contacting Google OID2 API. Thus, a RP is considered "registered" if its realm value has been used to contact our OID2 API.
This approach is obsolete as Google changed their auth to OAuth2
I didn't delete this answer because formerly approved api users are still valid to use.
== Original post below ==
If you are OWIN-based MVC5 user, just change Startup.Auth.cs file
app.UseGoogleAuthentication();
to
app.UseGoogleAuthentication(
clientId: "000-000.apps.googleusercontent.com",
clientSecret: "00000000000");
according to the http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on page.
Google has disabled OpenID2 for new domains. Existing relying parties can continue to use the API at least until the end of the deprecation period that runs through to April 2015. The announcement is at: https://developers.google.com/+/api/auth-migration#timetable

QuickBooks API no longer accepting my Access Token: token_rejected

I am connecting to the QB API using a Go library that I found for OAuth 1.0a: https://github.com/kurrik/oauth1a. I actually had everything working, and I cannot think of anything that I changed, but now every request I make is returned with token_rejected. From what I have read elsewhere, this usually means that my access token has expired, but even if I start the whole 3-legged OAuth process from the beginning I will get the same response as soon as I am verified. I have triple-checked my consumer key and secret, I know they are correct. I can plug in the Access Token and Secret created using the API Explorer into my code and it works just fine, so I know the problem is something related to the Access Token that I am getting back from QB. Everything looks OK when I print out the tokens that I am using, they do match what QB sends me back via the querystring after the handshake process. I have been banging my head against the wall all day now, any help would be great.
Just adding the answer, it was an issue with the Oauth Library code and is now resolved.
-Jarred

Resources