For an hybrid mobile app that I’m working on, I’ve implemented a two-factor authentication mechanism that returns a jwt to the mobile client. I’m looking for advise on how it can be used to sync data between Couchbase server and lite.
I’m pretty interested in a similar scheme, thanks for the article @thiagoalencar. The part that’s giving me pause is setting a random password. I asked a question in the gitter channel and apparently Persona and Facebook auth does something similar under the hood if automatic generation of accounts is enabled. The generated accounts just get a random password.
In theory it’s possible to authenticate with this password, and it would be possible to retrieve it from the admin port, so it feels like a needless point of access to secure. Any thoughts on ways to flat-out prevent password-based access and force JWT or another mechanism?
@william.r.tatum It’s not correct to say that you can retrieve this password from the admin port. A request for the user via the Admin port (via /db/_user/username) doesn’t include the password in the response.
Of course if you have Admin access via the Admin port you can just change the password for the user, so it’s correct to say that you can get access to the user via the admin port. That’s only one of many reasons that the admin port needs to be secured behind your firewall, though.
An update on JWT authentication in general - the upcoming Sync Gateway release (1.3) will support direct authentication against Sync Gateway using a JWT. We’re hoping to have a developer preview available within the next week, and we’d love any feedback you have on the JWT auth flow.
That’s 100% correct, not sure how I got that in my head. So it seems if the admin port is covered up (it needs to be in any case) then the only question is to make sure any randomly generated passwords are sufficiently unpredictable. Is there any way to hook into the RNG that’s used when a Persona or Facebook user is created, or do I need to supply my own random password when creating users from the admin port?
More specifically, Sync Gateway is adding support for OpenID Connect authentication, which includes direct JWT authentication when using the implicit flow. In most cases clients will authenticate and use the JWT token to obtain a Sync Gateway session (via the _session endpoint), to avoid the overhead of sending the JWT token on every request, but it’s not required.
The general lifecycle management for JWT tokens is via token expiry. If you want fine-grained control of session lifecycle, you could define a JWT with a short expiry, use it to obtain a session, and then manage the session as is done today.
Strictly from the Sync Gateway side, JWT verification is somewhat faster than session verification. It will depend on the signing algorithm used and the CPU on the machine, but generally the token validation is faster than session lookup in the bucket. However, given the average size of JWT tokens, there’s a performance hit on the transport side that will make session authentication more efficient in most cases.
If using the Auth Code flow (where the client is obtaining the ID token via Sync Gateway), SG will create a session by default when it returns the ID token to the client. The session creation can be disabled with a Sync Gateway config setting, but that’s the default behaviour.
If using the Implicit Flow (where the client obtains the ID token on its own), SG doesn’t do any automatic session creation, but clients can use the ID token to authenticate against the _session endpoint to obtain a session.
Yes, an ID token can be used for Sync Gateway authentication against any public REST API endpoint (just as if you were authenticating via basic auth, etc). This includes the _session endpoint, which can be used to get a session token/cookie for session-based authentication.