I am currently working through an implementation of a new mobile app.
The purpose of the application is to display data from a location where a location is a document in my main MongoDb database. The person logging into the app may have access to one or more locations and indeed during use of the app, they may have their access to all locations removed.
I have been looking at using a custom JWT for authentication and whilst the login itself is fine, we looked at implementing custom claims to see what location(s) the user has permission to. This solution has almost been discounted because it would require someone to continually login and out again to get the current locations they should have access to which in the real world is not viable.
My “perfect” solution is that I would use custom JWT auth to sign them into the app (ultimately the user records would be stored in Mongo) and then using the user id I have as part of that authentication I want to see which locations they have access to and more granular permissions at each location which I would be able to use.
Does this make sense and is this something I am able to achieve?
The reason I say this is when I have created an app utilising the custom JWT my understanding is that Realm confirms this custom JWT is valid and then uses its own authentication from this point which means the claims would only ever be re-read at the point of a fresh login.
I’ll have a look at the handbook link you’ve provided also (thank you for this also) to see if this will answer any of the questions I have.
That’s correct: the question however is, why would you delegate permissions to what should be exclusively an external authentication provider? You can certainly set specific permissions via Custom User Data, that travel in the Atlas JWT, and can be refreshed at any time (for example from Javascript). This way, you keep permissions where they belong, i.e. in the MongoDB user records.
This is indeed one of the typical use cases for Custom Data, the limitation is that, being part of a JWT, that in turn is sent in a HTTP header, it incurs in the limitations typical HTTP servers impose on headers’ size. In other words, you’ve a limit on how much data you can store in the JWT.