I’m interested in creating a public API for my Phoenix channels, so that clients in external apps can subscribe to their events. Additionally, the channels should require authentication from clients for them to start receiving events.
This is definitely possible with Phoenix, and I understand that the socket is exposed at localhost:4000/socket/websocket, but most of the examples I can find on the internet are focused on joins/subscriptions within the same app, rather than from outside the app. In other words, they rely on a token that’s created when you log in, and encoded in the HTML somewhere.
Does anyone have any examples of protected Channel topics that support authentication from external apps? For example, you connect to the socket, pass your credentials in a message to authenticate, and then you can subscribe to a specific channel? I can’t seem to find any to study, even though I would think this isn’t a unique use case. Of course, this could be very straightforward or I could be ignoring something obvious, in which case feel free to correct me. Thanks in advance!
The great thing about Channels is that you have complete control over the lifecycle. So you can use something like a Phoenix Token or a JWT out-of-the-box, or you could roll your own token exchange mechanism.
Do you currently have any mechanism for a person to register with your API? At work, we use OAuth to do so, which we then exchange for a JWT token on an edge server and pass around as JWT internally. You could do something similar where you take a token (any format, could even be an OAuth access token) and validate that against your database in the Phoenix.Socket connect/3 function.
There’s not much difference between a public and private API from an operational perspective. You need a different auth mechanism (usually), you need to make sure you don’t break the contract or existing users will be upset when their apps break, and you need to have good documentation. Other than that, I consider it business as usual.
That means I’d need to first make a request for the token via the REST API, then pass that token into the websocket parameters. That seems like a decent approach…the tokens are short-lived for security purposes, so I’d need to refresh every once in a while.
A bunch of other WebSockets APIs I’ve used have API keys that you pass in once via a message, and you’re authenticated for the life of the connection. I guess I was looking for something more along those lines, but the above could work for now.
You can take that approach too—although that’s not the point I tried to get across. If you go that route, you could remove the max age check (or set it very high) on the token verifier and it will change how long that token is good for.
I would personally not recommend connecting your public API credentials with your auth system. I’d recommend that you have a dedicated set of API access tokens that can be distinctly life cycled. The most simple example of this would be a table containing a hashed API token that associates to the user. When an API token is passed to your API, you check that the token is valid and then allow it. A more advanced implementation is something like an oauth2 server that has access and refresh tokens with different life spans
Unless I’m reading it incorrectly, the example above – which I’m using – encourages that. You authenticate with your credentials, it gives you an access token and a renew token, and you make all future requests using that token as your authorization. It stores the hashed token in a cache (Mnesia in my case). It uses the cache to check and make sure the token you’re passing is valid.
Maybe it’s a difference in how we define “public API”. That flow sounds like a normal “private API” flow for an app.
I typically view a public API as being one where you need to request a specific access token, you can delete it or make new ones, and they’re not tied to your logged in session at all.
One benefit of keeping them apart would be to consider if you needed to roll your user sessions. Hopefully it’s something you wouldn’t need to do often, but it happens. If you roll it via the same mechanism that access tokens are stored in, then it would break integrations. If it’s a separate mechanism, then you could treat them independently. Pow’s mechanisms may still allow you to treat them separate, but I think it generally uses one cache and data store for all credentials.
Pow may work for the task, but I’m not sure it would fit in my use cases.
What you’re saying makes sense. Basically you’re recommending I separate the API access tokens from my app’s session storage. That way I can roll sessions without affecting existing API tokens. I’d need to build a separate value store for that, of course, but it would work very similarly to the one I have set up now. Is that correct?
If so, that’s definitely something I’ll have to put on the list of things to do. Honestly, I don’t intend for actual users to subscribe to the sockets, it’s just for my other apps to track when messages get broadcast. So I don’t think there’s a huge concern to separate right now. If this solution works well, separating shouldn’t be too tough in the future when I’m the only user.
Word—if you’re just setting up your other apps to subscribe to the sockets, then I would go for the much lighter weight solution. Something like rolling credentials doesn’t really matter when it’s all in your control, because you know what to expect and can mitigate or ignore as necessary.
The solution I laid out would be for the type of system like when you setup auth with Github (which has access tokens and OAuth apps separated from other access).
@sb8244 My project’s requirements have grown; I’m ready to look into creating a separate store for API tokens. Do you know/recommend any open-source projects that implement that? They don’t have to be Elixir projects, I’m just looking for examples to study. Thanks!
