Authentication with json web token


#1

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.

Thanks,

Adrian

BTW - I’m using Couchbase-Lite-PhoneGap-Plugin.


#2

That’s kind of a broad request so I’m not sure exactly what you’re asking. Maybe the docs on custom authentication will help. If not, please be more specific about what you want to know…


#3

Thanks for the tip. I’ll give that a try.


#4

Hi, I don’t know if its too late but I’ve just released an article about it, I hope it helps:

http://ti.eng.br/couchbase-mobile-with-jwt-tokens/


#5

Thanks @thiagoalencar


#6

Hi @thiagoalencar I would love to take a look on your article, but it seems like the site is down. Any update on this will be appreciated. Thanks


#7

Thanks for letting me know about this. The website is back up again.
Best Regards,Thiago


#8

Thanks @thiagoalencar! Now it is working.


#9

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?


#10

@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.


#11

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.


#12

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?


#13

That’s a very exciting update, I wasn’t aware. I’m fairly new to the community, what’s the best place for me to watch for information about forthcoming releases?


#14

After some further discussion on the gitter channel it was suggested that I create a feature request. I’ll link it here for reference https://github.com/couchbase/sync_gateway/issues/1892


#15

Question about SG support JWT:

  1. When using JWT authentication, Is that means SG will not create a session for user(If SG connect to Couchbase Server, the _session:<session_id> document will not created?)
  2. If I want to remove some one’s session from server-side in JWT authentication mode, How can I do?
  3. When using JWT authentication, does this mean that every request to SG, SG will verify the JWT?
    If so, is it faster that Session verify?

#16

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.


#17

does this mean that SG will create a session for user (at the same time,if SG connect to Couchbase Server, the _session:<sessiion_id> will be created)?


#18

It depends on the authentication flow used.

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.


#19

does this mans that the client can use ID token as name to obtain a session,so CBL can then replicate with SG with this session?


#20

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.