How To Generate Token For Username And Password

[Alayna Rother]

Howevermy request seems to be invalid, as I receive the message ""error":"code":400,"message":"Unable to generate token.","details":["Invalid username or password."]". The credentials are 100% good.

Token based authentication is still supported. The error message indicates that your username and/or password was incorrect. When submitting a username directly to the REST API, as you are, the username is case sensitive. The username is not case-sensitive when submitting through the login prompt to ArcGIS Online. Try checking the case of your username and resubmitting the request.

Indeed, I did not check the case sensitivity of the username. Now, it works just fine. What I find awkward, is the different way of handling username by ArcGIS Online, which is why I stated my username was just fine as I could login to ArcGIS Online. Anyway, thank you very much for help!

Thank you!! I have been mulling over this issue for a while now trying to figure out why I could get a token from one ArcGIS Online account but not another running from the same script on the same machine etc. Turns out it was case sensitivity in the username as well. I find it odd that this isn't documented anywhere. I, along with probably a lot of other folks, assumed that wouldn't be an issue. I have been searching high and low and this is the only mention of case sensitivity regarding the username. Maybe I just missed that small but very important detail!? Anyhow, thank you again

This is a bit of a tricky concept. Changes were made to the ArcGIS Online sign in to work around the case sensitivity but you need to write in this code in custom scripts or be aware of the case of your username when making direct calls to the REST API.

I am an Auth0 noob, and am able to create a new user with the Management API after I get a token for the using the Management API for my specific Auth0 application. My question is, how do I procure a authentication JWT for a specific user using username and password, but with using API, not a browser based method like Lock. Please provide examples with links to the correct URLs within Auth0. I have been looking for this for a while now with no success. If I may provide general advice on your tutorials and documentation. I find you folks overuse several terms that is horribly confusing. These terms are API, application, client and token. It would be a lot easier with pictures. Thanks.

The Resource Owner Password endpoint can obtain an id_token through the API (non browser-based). Please ensure to read the Remarks about setting the grant_types for your client to support this endpoint:

Well, I tried the resource owner password endpoint, and I keep getting the following error:

"error":"unauthorized_client","error_description":"Grant type 'password' not allowed for the client.","error_uri":" -grant-types" I think we could benefit from a simple workflow for non-interactive clients to create a user and then get a token for that user.

Thanks, Prashant. I was able to get this working. So, I have management API working for creating users etc. and then the authentication API working for getting an access_token for a user. How does one validate a user for that access_token using your API (I assume use Authentication API, but what REST API)?.

Personal access tokens are intended to access GitHub resources on behalf of yourself. To access resources on behalf of an organization, or for long-lived integrations, you should use a GitHub App. For more information, see "About creating GitHub Apps."

GitHub currently supports two types of personal access tokens: fine-grained personal access tokens and personal access tokens (classic). GitHub recommends that you use fine-grained personal access tokens instead of personal access tokens (classic) whenever possible.

Organization owners can set a policy to restrict the access of personal access tokens (classic) to their organization. For more information, see "Setting a personal access token policy for your organization."

If you choose to use a personal access token (classic), keep in mind that it will grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account.

As a security precaution, GitHub automatically removes personal access tokens that haven't been used in a year. To provide additional security, we highly recommend adding an expiration to your personal access tokens.

Personal access tokens are like passwords, and they share the same inherent security risks. Before creating a new personal access token, consider if there is a more secure method of authentication available to you:

When using a personal access token in a script, you can store your token as a secret and run your script through GitHub Actions. For more information, see "Using secrets in GitHub Actions." You can also store your token as a Codespaces secret and run your script in Codespaces. For more information, see "Managing your account-specific secrets for GitHub Codespaces."

Under Resource owner, select a resource owner. The token will only be able to access resources owned by the selected resource owner. Organizations that you are a member of will not appear unless the organization opted in to fine-grained personal access tokens. For more information, see "Setting a personal access token policy for your organization."

Under Repository access, select which repositories you want the token to access. You should choose the minimal repository access that meets your needs. Tokens always include read-only access to all public repositories on GitHub.

Under Permissions, select which permissions to grant the token. Depending on which resource owner and which repository access you specified, there are repository, organization, and account permissions. You should choose the minimal permissions necessary for your needs.

The REST API reference document for each endpoint states whether the endpoint works with fine-grained personal access tokens and states what permissions are required in order for the token to use the endpoint. Some endpoints may require multiple permissions, and some endpoints may require one of multiple permissions. For an overview of which REST API endpoints a fine-grained personal access token can access with each permission, see "Permissions required for fine-grained personal access tokens."

If you selected an organization as the resource owner and the organization requires approval for fine-grained personal access tokens, then your token will be marked as pending until it is reviewed by an organization administrator. Your token will only be able to read public resources until it is approved. If you are an owner of the organization, your request is automatically approved. For more information, see "Reviewing and revoking personal access tokens in your organization."

Note: Organization owners can restrict the access of personal access token (classic) to their organization. If you try to use a personal access token (classic) to access resources in an organization that has disabled personal access token (classic) access, your request will fail with a 403 response. Instead, you must use a GitHub App, OAuth app, or fine-grained personal access token.

Note: Your personal access token (classic) can access every repository that you can access. GitHub recommends that you use fine-grained personal access tokens instead, which you can restrict to specific repositories. Fine-grained personal access tokens also enable you to specify fine-grained permissions instead of broad scopes.

Select the scopes you'd like to grant this token. To use your token to access repositories from the command line, select repo. A token with no assigned scopes can only access public information. For more information, see "Scopes for OAuth apps."

To use your token to access resources owned by an organization that uses SAML single sign-on, authorize the token. For more information, see "Authorizing a personal access token for use with SAML single sign-on" in the GitHub Enterprise Cloud documentation.

For example, to clone a repository on the command line you would enter the following git clone command. You would then be prompted to enter your username and password. When prompted for your password, enter your personal access token instead of a password.

Instead of manually entering your personal access token for every HTTPS Git operation, you can cache your personal access token with a Git client. Git will temporarily store your credentials in memory until an expiry interval has passed. You can also store the token in a plain text file that Git can read before every request. For more information, see "Caching your GitHub credentials in Git."

WHY not just pass the user name and password over HTTPS with every request instead of the access token. An access token will need to be verified with database and so is the combination of username/password. Why go through the added effort of access token if they do the same thing? I know I am missing something but I can't figure it out.

You are right in that an access token is verified pretty much the same way as a username and password. For the period when the access token is valid, it is pretty much equivalent to the username and password. In some cases (depending on your threat model) it may even be ok to send username and password with every request, maybe not from a mobile app, but for example in server to server requests, with appropriate controls.

The problem with a password (or with users, actually) is that they are reused. A password is a valuable target, because the same password is likely to be used on multiple services. So you exchange it for a shorter-lived access token, which, if stolen, presents less risk for your user. And you can't easily revoke a password - forcing users to change their passwords is a hassle. Revoking an acces stoken is easy.

3a8082e126