API / JWT / Mobile Client Authentication
We have an app that has mobile clients. We're migrating from a legacy code base and are evaluating authentication methods. I've looked at the Jumpstart code and it looks like the current method is authenticating API clients is through a JWT, which is connected in a 1 to Many with the User model.
1. Is there any provision, or plan for provision to provide for client side refresh of the token, or token expiration?
2. I expect that the intention is that each mobile client would have its own JWT, so we could expire 1 JWT without disconnecting the others. It that correct??
3. I see in the token, there is provision for 'metadata'. I assume that's for JWT payload. I see it in the DB, but I don't see that in the code anywhere.. Am I missing something??
Currently in our app, our mobile clients don't belong to a user. They belong to the 'account'. A user does connect the client initially, but afterwards each mobile client is managed by the account, much like a 'dumb time clock' on the wall. Our current app maintains configuration data for each mobile client, which is synced regularly to the client, and the mobile client transmits collected records, and information about the status of the mobile client (battery condition, OS version, etc) back application so we can monitor the health of the clients.
I can see potentially creating a 'dedicated mobile API user' for all of our mobile clients, and attaching tokens to each mobile client. (we regularly have 50+ mobiles phones per app instance) It seems like we would want an additional model to contain the mobile dynamic information (OS, battery, etc) and potentially put the config information in the token. Does that sound reasonable?? The potential issue with storing info in a JWT is what happens if the client needs to update it's config? It is within the scope of a JWT to take info from a client and update server based payload data, as long as it's not 'auth' data?
If anybody can help me understand the convention around mobile auth / tokens / device state I'd appreciate it, or point me to what 'everybody else does'.
1. Is there any provision, or plan for provision to provide for client side refresh of the token, or token expiration?
2. I expect that the intention is that each mobile client would have its own JWT, so we could expire 1 JWT without disconnecting the others. It that correct??
3. I see in the token, there is provision for 'metadata'. I assume that's for JWT payload. I see it in the DB, but I don't see that in the code anywhere.. Am I missing something??
Currently in our app, our mobile clients don't belong to a user. They belong to the 'account'. A user does connect the client initially, but afterwards each mobile client is managed by the account, much like a 'dumb time clock' on the wall. Our current app maintains configuration data for each mobile client, which is synced regularly to the client, and the mobile client transmits collected records, and information about the status of the mobile client (battery condition, OS version, etc) back application so we can monitor the health of the clients.
I can see potentially creating a 'dedicated mobile API user' for all of our mobile clients, and attaching tokens to each mobile client. (we regularly have 50+ mobiles phones per app instance) It seems like we would want an additional model to contain the mobile dynamic information (OS, battery, etc) and potentially put the config information in the token. Does that sound reasonable?? The potential issue with storing info in a JWT is what happens if the client needs to update it's config? It is within the scope of a JWT to take info from a client and update server based payload data, as long as it's not 'auth' data?
If anybody can help me understand the convention around mobile auth / tokens / device state I'd appreciate it, or point me to what 'everybody else does'.
Notifications
You’re not receiving notifications from this thread.