Earthdata Forum

Hi,

I have a Python script that leverages the earthaccess Python API to download NASA SMAP data every 8 days.
I currently have a personal Earthdata login and am using my username and password to authenticate to earthaccess each time the script runs, following the documentation here: https://earthaccess.readthedocs.io/en/latest/howto/authenticate/

I am trying to determine if there is a way to set up a service-account type user (e.g. "headless" user) so that I don't have to have my account tied to this automated process.

Thanks for the assistance and advice.

Thank you for reaching out. There are service-type accounts for Earthdata login. If you go to your profile at urs.earthdata.nasa.gov/profile, you'll see an option under "User type" for converting a user type to a service account. I believe these were offered as an option when the plan was to require rotating passwords for Earthdata login.

Another option might be to create a separate Earthdata login that you use just for programmatic access, although I think it would require a different email than your personal one. I'm checking on this and will circle back.

Kind regards,

Mikala

I see the following options for User Type (after clicking my Edit Profile tab):

- Production User
- Science Team
- QA Testing User
- Data Provider Internal User
- Public User
- Application

Oddly, I noticed that my User Type was set to Application. I have no idea why.

Does the "Application" User Type represent a "service account"?

More generally, is there any documentation on how the various User Types are intended to be used?

If I were to create a "service account" (for programmatic access), is there an appropriate User Type that would allow me to NOT have to generate a new token every 60 days for a production application that is integrated with another system that requires our app to supply a token? Having to do this every 60 days is very annoying for production maintenance, so it would be fantastic to be able set things up to eliminate this maintenance burden.

Those are all great questions! I've reached out to someone internally to get some more information about all of this. More to come!

Some updates on service account questions.

I am trying to determine if there is a way to set up a service-account type user (e.g. "headless" user) so that I don't have to have my account tied to this automated process.

The general answer is that there is no distinction between user accounts and service accounts - the user is free to use their existing account for that purpose, or set up a new account. That said, two accounts cannot share a single email.

Does the "Application" User Type represent a "service account"? More generally, is there any documentation on how the various User Types are intended to be used?

This field is purely to let users self-describe their use case - it has no impact on functionality, and should be set however the user sees fit.

If I were to create a "service account" (for programmatic access), is there an appropriate User Type that would allow me to NOT have to generate a new token every 60 days for a production application that is integrated with another system that requires our app to supply a token?

No, but tokens can be created programmatically via the find_or_create_token endpoint: https://urs.earthdata.nasa.gov/documentation/for_users/user_token#/api/users/find_or_create_token
This API route will let you avoid manual token swapping in a single call.

Thanks for the clarifications. That helps immensely.

Regarding use of the find_or_create_token endpoint, that requires use of an account's username/password creds, but our use of a token is specifically to avoid having to configure our app to use such creds in the first place, so this defeats that for us.

However, we'll likely adjust our app to instead use a configured username/password pair for a to-be-created "service" account so that the app can then use the configured creds to obtain tokens via that endpoint, instead of directly configuring a manually obtained token.

Thank you all for the information and responses here.