Generate Token With Username And Password

[Oswald Lemus]

WHYnot 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.

Also it's very unlikely, but sometimes there are vulnerabilities in TLS - not very often, but there have been a few in the past years. Such a vulnerability might allow an attacker to decrypt some of the traffic sent over https, or for example there was a vulnerability in openssl a while ago that allowed attackers to extract parts of the server memory, potentially holding whatever the user(s) sent. It's much better if it's just an access token, and not the actual password.

Another point is sometimes (in OAuth flows) your app won't be allowed to even access the actual password. When your user logs in with a 3rd party identity provider (like for example facebook), they would not like your app to receive their facebook password. They just go to facebook, exchange their credentials for an access token, and you only see the token which you can verify with facebook if you want. But you never actually get the user's facebook password. Of course this is only valid when the identity provider is a third party.

Access tokens (in most services) can be easily generated, blocked, monitored for their usage & statistics from your account, can be set as expirable, can have restricted permissions, and so on... Of course, you can delete it at all. The Username & Password is the master, who can control the access tokens.

Access tokens are safer as I said, and that is the most important thing. If you use Username & password in your web-application (or whatever) and that application is hacked (which happens so frequently), or someone views its source, or even some log-system saves the request parameters - then your user & password can be viewed by 3-rd parties and all your account can be hacked (and probably others too, where you have same user/pw). Access tokens eliminate all these risks.

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)?.

However, my 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.

Hi Dan, I noodled around with this a bit. Not sure how this would work. I did note that if I put in bogus credentials, I get back an error that it cannot generate a token (which makes sense). I guess my question is still how would I skip the user/pass checking if I already have a token that was supplied?

I king of suspected that (my edit about not getting it any further), but thought that might help you or others in future. I also would like a headless option. Trying to set things up for not admin users.

Indeed, hard-coding the password was what I was trying to avoid... I was thinking of generating a token (they seem to have a 2-week max length for AGOL) on some interval and putting it somewhere my code can access it, but no such luck. Generating a profile will at least get the storage out of my code and my Git repo, but it's still in clear text on the hard drive...

The authentication is handled when you call gis class in the ArcGIS Python API. Using the python API, tokens and authentication are provided by the api so you don't need to manually create and append tokens to each request. YOu can still use tokens and send direct rest calls using the rest api if desired:

As a rule of thumb, never embed a token or username and password in a script that users have access to. With any of these components a potentially malicious user could access your content and resources as your username. If you are looking to authenticate on behalf of users in a public application, check out the app login workflow:

We are creating an user interface for Cloud JIRA to get test cases in JIRA via API . The user will be entering user name and password for the login into user Interface. In the API authentication is done via user email Id and API token token but in the UI user will be providing only his username and password. So we need a way to authenticate the user using the API with only username and password from the user.

There are situations when it is not possible to use a secure OAuth 2.0 flow to obtain an access token. This is most common when developing command line applications, scripting with the ArcGIS API for Python, or when using the ArcGIS REST APIs. The generateToken operation allows you to get an access token using your username and password. This flow adheres to the resource owner password credentials grant type defined in the OAuth 2.0 specification.

Obtaining an access token with this method will expose the username and password credentials as plain text and could present a potential security risk. It is strongly recommended that you implement a secure OAuth 2.0 flow whenever possible in your applications.

Using a username and password is useful in some cases, such as DevOps scenarios. However, if you want to use a username and password in interactive scenarios where you provide your own UI, consider moving away from it.

The preferred flow for acquiring a token silently on Windows is using the Windows authentication broker. Alternatively, developers can also use the Device code flow on devices without access to the web browser.

If you're building a desktop application that signs in users with social identities using the Resource Owner Password Credentials (ROPC) flow, see how to sign in users with social identities by using Azure AD B2C

This extract is from the MSAL Node dev samples. In the following code snippet, the username and password are hardcoded for illustration purposes only. This should be avoided in production. Instead, a basic UI prompting the user to enter her username/password would be recommended.

3a8082e126