In this meeting, the State Changers addressed two main topics pertaining to the Xano platform: the creation of a bearer token model and how to optimize the security of this model.
They discussed using the Xano built-in token for primary API authorization, with the user generating a token that functions as their secret upon login. Concerns were raised about Xano's use of cryptographic-based authentication, which gives less control over issued tokens. Two security architecture solutions were proposed: 1. Implementing a "Client Credentials" type flow, where a long-term token could be issued, used primarily for server-to-server communication and authorized through OAuth. This token would only permit access to a single endpoint, which issues a temporary token for use with the rest of the endpoints. 2. Using an API key-like structure, more manually controlled by maintaining multiple API keys for revoking and key rotation capabilities. This would involve the building of a custom function that checks authorization at the beginning of every endpoint. While the first approach offers a higher level of control and safety, it potentially complicates client-side operations by requiring two transactions. On the other hand, the second approach might impose more responsibility and complexity on the Xano users, but offers more control due to its manual nature. The conversation touched on areas such as security revolving around key rotation and expiration, the role of SDKs in handling intermediate steps, and comparison of the security architecture of real-life applications such as Google and Stripe. The State Changers also explored how to extract and validate tokens, how to check database values, and how to manage roles or scopes in OAuth to authorize specific token actions.
(Source: Office Hours 10/10/2023 )
