Unable to perform any authorized API calls using the Blackberry UEM REST API service. I'm running a trial cloud instance of Blackbery UEM and calls to "ping" and "authorization" works. However, after obtaining the authorization code, using it on any REST calls fails with the error 401 Unauthorized.
The credential used is of an administrator with the "Security Administrator" role which has full permission. I have also tried the above in postman and also the sample PowerShell command, but the results are the same.
Does anyone know what's going on wrong here? Am I missing any configuration? I am going a bit crazy... Thanks.
if you get a 401 error, its almost always an issue with the account/authorization your using.
Since your connecting to the cloud instance of UEM, it ONLY support OAuth authentication. For this to work, you will need an token, not an authorization code. Here is a devblog.blackberry.com entry on the steps: https://devblog.blackberry.com/en/2020/07/new-authentication-option-for-rest-apis-oauth.
Give that a try instead.
Related
Hi I am trying to access the microsoft graph endpoint https://graph.microsoft.com/v1.0/me/contacts but I receive a 404.
** ISSUES IT SHOULDN'T BE **
it should not be the problem with the exchange mailbox, since it works for the user in the explorer
it's not the code, since the token from the graph explorer works in the code
both tokens seems to have the same permissions
The image below is a picture of the decoded accesstoken, one is from the graph explorer and one is a token received from my own Oauth flow (auth code grant), they are trying to access the same users contacts.
Anyone know what I am doing wrong?
To access the https://graph.microsoft.com/v1.0/me/contacts, I think "Contacts.ReadWrite" permission is also required which is missing in the scopes of the above image. Can you please check the permissions here:https://learn.microsoft.com/en-us/graph/api/user-list-contacts?view=graph-rest-1.0&tabs=http#permissions.
Hope this resolves the issue. If not please share Client request id and timestamp of the query.
I try to call Microsoft Graph APIs reports call: https://graph.microsoft.com/beta/reports/getOffice365ActiveUserDetail(period='D7')
But it fails with error HTTP 403. Is there a way exists to overcome this?
With Microsoft Graph explorer i can repro the issue with the same API call. HTTP 403 is forbidden error. It tells that you're not allowed or dont have permission to call the API. Make sure you have necessary permissions.
Tried updating the permission "Reports.Read.all", with admin consent provided so i can read all the usage reports. Now, i tried with Graph explorer, and it works for me.
You tested the same, confirmed it works for you.
Here's the related documentation!!
As #Dev said,please add the Delegated permisson or the Application permission below and test it again.
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!
I have an interesting problem. We have set up the Thinktecture Authorization Server from the trusty Identity Server 2 and gotten it to work a few months back. It is configured as a relying party for an already existing corporate identity server, so when we use the Code Flow example, click the "Start authorization handshake" we bounce over to the identity server, supply our credentials and get bounced back to the callback of the code flow with an access code, click the Get Token, and are granted with this fine jwt token. All seems fine.
However,
When we try this either from, for instance, postman, or our app development team from their development devices (android and iphone), it starts fine but when we call the token endpoint with our newly minted access code we get an "Anonymous client" response.
Looking at the web example from the CodeFlow example I see it posts basic authentication including a base64 value of the secret wich is missing from postman and our app team. I see no reference to this in the CodeFlow example so I have no idea where this comes from. If I hard code the Authorization BASIC [including the Base64 secret I snatched from the previous example] it does not change anything.
We'be been stuck for several days on this so any help would be gratefully appreciated. Any Ideas?
After a lot of recearch and hair pulling it seems the Postman client we are using does not support Code Flow and therefore does not include the Authorisation header we are missing. After capturing the traffic from Postman with Fiddler we manually added the basic authorization header with the client name and secret and got everything working. So as of now, postman does not work.
I hope postman does add support for codeflow in the future.
Atli
I'm trying to implement Google OAuth 2 to get access to Google APIs. I follow this guide, using server-side scenario.
I have no problem with getting the code, server redirects to localhost (which is the only server allowed in redirect URIs for now).
To achieve this, I go to https://accounts.google.com/o/oauth2/auth?client_id=whatever.apps.googleusercontent.com&redirect_uri=http://localhost/&scope=https://www.google.com/m8/feeds/&response_type=code page.
Then, I tried using curl (as in guide) to test, if Google's server responds with access token. However, it seems to fail very hard. Only response I can get is {"error":"invalid_client"}. I'm sure I provide everything Google wants me to provide - code, client ID, client secret, redirect URI (localhost) and grant_type=authorization_code.
Whole curl command line is:
curl https://accounts.google.com/o/oauth2/token -d "code=<code>&client_id=whatever.apps.googleusercontent.com&client_secret=<won't tell!>&redirect_uri=http://localhost&grant_type=authorization_code"
Am I missing something? How can I exchange code for access token?
Did you urlencode your client secret and redirect url? That works for me.
Should be http%3A%2F%2Flocalhost instead of https://localhost.
I had the same error until I realized that I was trying to connect with a client ID which I created for iOS. So for me the solution was to create a new API key-secret pair on the API Console with the platform set to "other".
Now I'm getting other errors but that's another story. ;)
Happens when you use wrong Client secret. Make sure you are using correct Client secret from Google API console. I was using Email address since API console displays the information in the following order:
Client ID
Email address
Client secret