I have a remote service which need to make a call back to Litium at request. You could think of it almost as a webhook. The call back must be authenticated but I don’t want the remote service to be able to authenticate on it’s own.
My idea goes like this:
Something happens in Litium that requires the remote server to fetch data from Litium
Litium pre-generates a JWT token and hands over to remote server in a kind of “here, use this to get your data” routine.
The remove server makes the authenticated call back to Litium
Now how would I go about generating the token on Litium side, short of making a request to /litium/oauth/token? There must be a simpler way, right?
Didn’t get that to work with service accounts. I ended up using a different approach for authentication altogether though, so I don’t really need this anymore.
I think this is a really interesting discussion, can you explain your alternative way?
If we should build anything in the platform, how do you think that should work? Example should the ticket that will be included in the request be scope limited, time limited etc.
My alternative way was pretty simple. Since my handler was the one receiving the request back from the external service, I simply put together my own JWT token, signed it with the machine key and sent it along. I gave it a short expiry time (few minutes), and then I simply validate the token when the request came back.
For the platform, I could see it useful to be able to provide short-lived tokens that could give access to Litium’s web apis. But that should probably also limit the accessibility. You don’t want to hand someone a master key to wreak havoc even if it’s just for a minute
