Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Internal API capability for Service Accounts #156

Closed
dealproc opened this Issue · 5 comments

2 participants

@dealproc

When you sign-up for Amazon's Kindle service, you join your "device" to your account, and then can manage whether the device is still valid on your account or not from a Management UI that is not their Identity or Authorization server, as best as I can tell.

My opinion here is that it would be nice if there would be a way for a management portal to be given a token to connect to something in AS and be able to, via an API call, manage the issued tokens for a list of "devices" which are really service accounts.

@dealproc

As an alternative, can we call into AS using the ResourceOwnerPasswordFlow, then call the API that is used in the AS User Interface to clear all "client" tokens when we want to kill all authorized tokens?

There is currently functionality for an end user to do this, I'm asking if it's possible to do this as the service account, and if so, what security implications would we be facing?

@leastprivilege

We don't expose functionality like that to external clients. I don't an issue building something like this yourself. Just make sure you have tight authorization on it ;)

@leastprivilege leastprivilege self-assigned this
@dealproc

So i guess the deeper question is: does it make sense to use the APIs you already have in-place for the WebUI of Authorization Server, or does it make sense to build yet another "Internal API" site for managing the credentials for Authorization Server's tokens that it issues?

In reality, since this is ResourceOwnerPasswordFlow, and our product has the username/passwords available for the service accounts, it seems like it may make sense to do the login scenario and just automate the web services that are already built into AuthorizationServer, and just call "Delete" in these scenarios. I am just concerned what security implications we may face, if any.

@leastprivilege

I would not re-use the ones we have - they were not really designed to be used by anything else than the internal admin UI only.

Build proper OAuth2 protected resources that call into our logic or database.

@leastprivilege

OK?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.