Expose Auth Token to API user for CLI Client

[PeopleMakeCulture]

From @shreddd in Slack

We need to address a programmatic access use case from JGI and I wanted to understand how best to support this. The simple (hopefully) thing we would like short term is being able to quickly get the access token (bearer token) that an API user can use in a CLI client. Right now it requires a somewhat hacky approach to introspect the outgoing call or looking at the Curl dump of the call.

Related to #404

[PeopleMakeCulture]

Additional Context:
you can use the /users/token endpoint with grant type "password" and a username and password. the response will contain an access token of token type "bearer" and an expiration datetime:

    return {
        "access_token": access_token,
        "token_type": "bearer",
        "expires": ACCESS_TOKEN_EXPIRES.model_dump(),
    }

[PeopleMakeCulture]

@shreddd could you clarify if they would want to log in via an ORCiD, or with the username/password flow, or both?

[dwinston]

If you POST /token with grant_type=client_credentials and client_id={KNOWN_ORCID_JWT}, then the response will be {"access_token": ..., "token_type": "bearer", "expires": ...} as above. So, this could work as is until we perhaps have a more streamlined credentials flow without "sites" etc.

[dwinston]

(waiting on use case confirmation/clarification)

[shreddd]

I think this is OK but seems like an extra step? The goal is to see if we can provide a token to the user for easy use. Poking at the code a bit I noticed that once logged into swagger we use a cookie to talk to the server - wondering if we could take advantage of this. Will follow up on Slack and post updates here.

Given that we already have a cookie for logged in user, is it possible to use that cookie to get and display the token? This could potentially live in the custom HTML? One option - would it be possible to display the access token from: https://github.com/microbiomedata/nmdc-runtime/blob/main/nmdc_runtime/api/main.py#L483

[shreddd]

We want this for both. Basically we always want to give the users an easy way to look at their token if they need it.

@PeopleMakeCulture

@shreddd could you clarify if they would want to log in via an ORCiD, or with the username/password flow, or both?

[PeopleMakeCulture]

@shreddd Could you explain how you're thinking about programmatically accessing the cookie to access the token?

One thing we could do is refactor the code below into its own endpoint, so that a user can POST their JWT and GET a bearer token. Is that what you had in mind?

    if user_id_token:
        # get bearer token
        rv = requests.post(
            url=f"{BASE_URL_EXTERNAL}/token",
            data={
                "client_id": user_id_token,
                "client_secret": "",
                "grant_type": "client_credentials",
            },
            headers={
                "Content-type": "application/x-www-form-urlencoded",
                "Accept": "application/json",
            },
        )
        if rv.status_code != 200:
            rv.reason = rv.text
            rv.raise_for_status()
        access_token = rv.json()["access_token"]

[dwinston]

possibility: add bearer token info to GET /users/me response.