Token Profile Providers - Which Languages and What Providers?

[fundthmcalculus]

Outcome

• A matrix of languages and profile provider implementations that we should support.
• Decision on how to handle multiple (?named?) profiles on the same system.

Questions that Need Answered

1. File based token storage - definitely .NET, Go, Java/Kotlin, Python, others?
2. Mobile based profile storage - definitely .NET, Java/Kotlin, Swift, others?
3. Browser based profile storage - definitely .NET, Javascript (node/web), others?
4. Should we support other ways of storing/recalling profiles?
5. Should we have named profiles? - definitely useful for development/pipeline testing. Useful in production down the road?
6. If named profiles, how to handle them?

Background PR: https://github.com/trinsic-id/sdk/pull/492

[sethjback]

I posted a comment at the bottom of #460 that is relevant here.

[tmarkovski]

@sethjback do you mind copy/pasting the comment here? You make some good points on using contexts that we should drill down further.

@fundthmcalculus your grouping is on point. As a general rule, file system storage should be supported for all server based applications, and mobile/browser for client applications. In fact, most deployed server apps will just pass the token from configuration, so the token provider might now even be that important.
Filesystem can also be used for mobile, since the platform provide app specific data that can also be synced, but this is not the preferred way, although not uncommon.
Browser based applications should use localStorage, unless we think there's a better way.

In terms of multi user support, what are some common use cases that we anticipate this being used?

[sethjback]

@tmarkovski latest PR with token storage got me thinking and I wonder if it would be helpful to think of this in terms of contexts that can be set and used. This thinking is heavily influenced by how kubectl manages configs across multiple cluster, but it works pretty well and seems like it might be applicable here. Just food for conversation.

There are several pieces of information that combined equate to a successful auth: 1. environment (prod/staging/dev), 2. ecosystem, 3. token. All 3 of those need to match in order for auth to succeed. The proposal would be to combine those into a context that can be named and set.

So, for example, you could define the environment:

{
  name: "prod",
  serverEndpoint: "prod.trinsic.cloud",
  serverPort: 443,
  serverUseTLS: true
}

The Ecosystem:

{
  name: "Test",
  id: <id>
}

The AuthToken:

{
  name: "apiToken",
  token: "...."
}

And combine those into a context:

{
  name: "prod-test-api",
  environment: "prod",
  ecosystem: "Test",
  token: "apiToken"
}

Then you could do something like <service>.UseContext(name) and it would use the provided values. Obviously we would need to have reasonable defaults set for all of those values, but it seems like this would allow easy switching between values.

There could be a default context that just takes whatever the current values are if the user doesn't explicitly create one. E.g., if a dev calls SignIn the returned auth token, ecosystemid, and environment would all be set as the default. We could expose a SaveContext(...) that allows providing all the values, and maybe a SaveCurrentContext(<name>) that would take the current values and save them as the context name.

[fundthmcalculus]

Then you could do something like .UseContext(name) and it would use the provided values. Obviously we would need to have reasonable defaults set for all of those values, but it seems like this would allow easy switching between values.
There could be a default context that just takes whatever the current values are if the user doesn't explicitly create one. E.g., if a dev calls SignIn the returned auth token, ecosystemid, and environment would all be set as the default. We could expose a SaveContext(...) that allows providing all the values, and maybe a SaveCurrentContext() that would take the current values and save them as the context name.

I really like this setup. We could easily implement it across languages. Any objections to this being the route we go? This also eliminates the the issues with needing channel reuse if you can simply change the context target on the fly.

[janpieterz]

Reading this I don't really get the context I need to understand this (I am new 🎉 ). Care to elaborate this a bit further @fundthmcalculus ?

[fundthmcalculus]

Reading this I don't really get the context I need to understand this (I am new 🎉 ). Care to elaborate this a bit further @fundthmcalculus ?

The question is: how do we handle storing/recalling authentication tokens? Eg, once the user has signed in, and they want to persist the auth token. Do we provide a sanctiond/out-of-the-box method for doing this? If so, how?

There's an argument that the customer knows best how to store that authentication token in the context (🥁 ) of their application. At the same time, having an out-of-the-box storage mechanism in the SDKs would also reduce friction for the users. There are some initial prototypes that TM has done in the .NET SDK, but none of it is finalized.

[janpieterz]

I see, my 10 cents: for now I’d say we shelve it, unless customers come to us wanting more tools. Deciding storage is very environment dependent. Does shelving sound ok? We should add some guidance towards browser usage (see studio security discussion), and add some “How to store your auth token” section to the docs adding our tips? Kind regards, Jan-Pieter George

…

On 25 Jul 2022, at 15:24, Scott Phillips ***@***.***> wrote:  Reading this I don't really get the context I need to understand this (I am new 🎉 ). Care to elaborate this a bit further @fundthmcalculus ? The question is: how do we handle storing/recalling authentication tokens? Eg, once the user has signed in, and they want to persist the auth token. Do we provide a sanctiond/out-of-the-box method for doing this? If so, how? There's an argument that the customer knows best how to store that authentication token in the context (🥁 ) of their application. At the same time, having an out-of-the-box storage mechanism in the SDKs would also reduce friction for the users. There are some initial prototypes that TM has done in the .NET SDK, but none of it is finalized. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[fundthmcalculus]

I see, my 10 cents: for now I’d say we shelve it, unless customers come to us wanting more tools. Deciding storage is very environment dependent. Does shelving sound ok? We should add some guidance towards browser usage (see studio security discussion), and add some “How to store your auth token” section to the docs adding our tips?

10b I see what you did there 👍 . I agree with shelving the discussion. In that event, let's close this ticket, and we can open a new one when we have more specific needs.