OAuth 2 Authentication and Plumber APIs

[Marco-R]

Hi,

up to now we have been using our Posit Connect with LDAP/AD Authentication and have been hosting Plumber APIs as interfaces to our models for other applications in our organization.

As per the latest changes, it is not possible anymore for Anonymous users (or Applications in our case) to use interactive content, such as Plumber APIs.

Hence, we changed to OAuth2 Authentication, following the migration guide and everything. On the user level everything works as intended.

Our understanding was, that we can now let Applications use our Plumber APIs via JWT token.

We generated a token and created a user on the Connect server by API with the email identity just like on our OAuth2 instance with the same UUID.

Afterwards we try to call our Plumber API like this:

library(httr)
myurl = "https://ourConnect/PlumberEndPoint"
accessToken =  'myJWT'
bdy = read_lines("myTst.json")
headers  = add_headers(Authorization = paste0("Bearer ", accessToken))
res = POST(url= myurl, config = headers, body = bdy, encode = "raw")

We end up with this error message:

res$status_code
[1] 401
res$content
{"code":30,"error":"We couldn't log you in with the provided credentials. Please ask your administrator for assistance.","payload":null}

Does someone have a solution to this particular problem or does somebody know how we can make our Connect hosted Plumber APIs available to different Applications throughout our company?

[edavidaja]

The API key you need to access content will come from Connect:

https://docs.posit.co/connect/user/api-keys/#api-keys-creating

[Marco-R]

Thank you for pointing me into that direction. I understand that solution in the context of a real user.

But what about services? -Will we consequently need to tie services to users?
Or is there a way to create an API key for another user (in our case the service account) programmatically?

[edavidaja]

Connect doesn't currently have a notion of service accounts, so in your context you would probably want to create a service user from your identity provider that you use to grant access to content. Since Connect API keys get the permissions of the account they are provisioned by, you may want this account to be a Viewer on Connect.

[Marco-R]

That's what we did, thus I marked your answer as a solution.
Thank you very much.