Let's say I have a gitlab access token (generated and given to an application by a user). I can find if that token can be used to read from a repository by actually trying to read some data and seeing if that operation succeeds.
How do I find whether that token has write permissions (making commits) for a specific repository?
Beside trying a write operation, I don't know of an API which would be able to get the scope of a token.
As this issue illustrates, the scope is what you are looking for: "Limiting scopes of a personal access token"
Check if your token is listed when getting impersonation tokens: that API returns associated scopes.
Related
I'm attempting to use a GitHub Personal Access Token to create a repository webhook on a private GitHub repository my user has access to.
Since this PAT is being used by an automated script, I want its scope to be as limited as possible. As such, I created a PAT with only the admin:repo_hook scope. It seems this scope is too limited, however, as a POST to https://api.github.com/repos/ORGANIZATION/REPO/hooks is returning a 404.
(I've confirmed the repository name and organization name match. The 404 may indicate that the token does not have sufficient permissions to see the repo, as described here)
The API supports Basic Authentication as defined in RFC2617 with a few slight differences. The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found.
What scopes do I need to add to my Personal Access Token to successfully create a repository webhook?
I figured it out. One additional requirement I overlooked in this case: the user in question wasn't actually an Admin on the repository, meaning even a PAT with full permissions would be unable to create a webhook.
Upgrading the user to Admin on the relevant repository was sufficient to solve this problem.
I am trying to use MSAL to authenticate to ADO in my automation. I have started with the samples at https://github.com/microsoft/azure-devops-auth-samples/tree/master/ManagedClientConsoleAppSample. I have created an Application in my AAD tenant, and when I run SignInUserAndGetTokenUsingMSAL it brings up a browser window and prompts for the user. Once that is complete, I can paste the returned token into a token decoder, and it has a valid token that has the values I expect. But when the sample calls _apis/projects?stateFilter=All&api-version=2.2 it is returning a 404 Not Found. There are multiple projects in my ADO organization, and I expected there to be results. In order to test if the returned token is good, I added a call to https://{AccountName}.vssps.visualstudio.com/" from https://github.com/microsoft/azure-devops-auth-samples/blob/master/ManagedClientConsoleAppSample/Program.cs to the original sample. It returns a json object that matches my user.
I think that there is some permission issue with my user, but I don't know what permission I am missing. Can anyone point me to what permissions I should verify, or what other debugging I can do to find the problem?
So I wish to use an Emacs plugin called grip-mode, which uses an application called grip under the hood that uses GitHub’s API to render markdown text. But unless an access token (which can have an empty scope) is provided, it hits GitHub’s hourly rate limits. So I want to put an empty-scoped access token for grip-mode. Problem is, my Emacs configuration is stored in a public repository, and so, I want to make sure an access token with an empty scope can’t be used maliciously before I put it in my configuration. So, can an empty-scoped access token be used maliciously? Or is it harmless to use it?
Not a complete answer, but at least one can use the PAT to consume your API limits, either by using the plugin normally or using the token maliciously.
From GitHub docs:
Authenticated requests are associated with the authenticated user, regardless of whether Basic Authentication or an OAuth token was used.
For example they can scrape PATs exposed on GitHub and use the tokens to perform high-rate API calls.
Or if one of your user use the token frequently, all other users will not be able to use the plugin.
Also, GitHub does not recommend using your PAT in this case
I'm trying to figure out how to use the Azure Graph API to query a user's full name (first and last) from a given username. I understand I can do this with the following Graph API call...
https://graph.windows.net/myorganization/users/{user_id}?api-version
However, I am not sure how I go about getting an access token to use with this, because this process will be called without a user logging in, which is usually how we obtain an access token.
Is there anyway I can pass a username/password to a given URL using cURL or something and obtain an access token that way, so it is done behind-the-scenes?
There are two main authentication methods which are supported by OAuth 2:
Authorization Code Grant Flow
Client Credentials Grant Flow
The first flow requires a user agent to be present to sign into the client service and results in a delegated token. The second method does not require a user to sign in, as it only authenticates using the client secret; this results in an app only token.
If you want to create a background service that captures data from the AAD Graph API, you can absolutely do this using the Client Credentials Grant Flow, which does not require a user to be present at any point during the authentication flow.
You simply need to configure your application to to have app only scopes. Read here: Permission scopes | Graph API concepts. App only scopes all require tenant administrators to consent to the application in order to get access to data.
Finally, I feel I must mention that there is another less used flow specified in the OAuth 2 spec: Resource Owner Password Credentials Grant. This flow specifies how a client application who has knowledge of a user's username and password could directly pass those parameters and get an access token on behalf of the user. However using this flow is not good practice at all.
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
We support this in our V1 endpoint, but not in our new V2 endpoint. You can read this blog to learn more.
I'm trying to make a call to the new Office 365 File REST APIs. (As explained here).
I'm using Postman rest client to send the request.
I have registered my application in Azure AD and given it full permissions to 'Office 365 SharePoint Online'.
I can successfully get an authorization token using the clientId generated in Azure AD.
However when I attempt to list files, using the access token I get an error.
------------------
RESOURCE HTTP GET:
------------------
URL: https://<OUR_DOMAIN>-my.sharepoint.com/personal/<user_domain>/_api/Files
HEADER: Authorization: Bearer <access token>
Response:
3001000;reason="There has been an error authenticating the request.";category="invalid_client"
What can cause this issue?
Not sure what steps you've tried to use to resolve this, so it's hard to help you out here. I've just finished writing up more detailed instructions on the steps to register an app to call OneDrive for Business. It's long and complicated right now, but we're working to make things better in the future.
You can check out the details of how to do auth here: https://dev.onedrive.com/auth/aad_oauth.htm
Make sure you aren't asking for too many permissions, since that will require your app to be authenticated by an admin instead of the end user. For most apps, you can just use the "My files" permission scopes which can be accepted by the user of your app directly.
If you post more information about what calls you're making, responses, and app configuration in AAD I might be able to help more.
You may have been using different resources.
Check whether the resource which you have used for getting access token is same as which you are requesting for getting files.
for example :
If the resource which you have mentioned while requesting access token be :: "https://tenant-my.sharepoint.com/"
Then you need to make request on the same resource for accessing files :: "https://tenant-my.sharepoint.com/_api/v2.0/drive/root/children"
The above request give list of root children.
tenant --> domain name which was registered to your organisation.
Follow this documentation for further accessing the api