API authorization with roles

[afsharm]

Research, design and implement a solution for authorizing APIs with roles.

An API may be called by third parties such as an organization's internal web application, a mobile device, etc. This is mostly the case when headless part of the project is emphasized.

Roles can specify which operation a user can do or cannot do regarding a resource.

Right now, authentication/authorization is implemented by help of JWT. For this task, PKCE (OAuth 2.0) maybe used. It needs more research.

[pournasserian]

JWT (JSON Web Tokens)

Pros:

• Simplicity: JWT is straightforward and easy to implement.
• Stateless: Once issued, tokens are self-contained and do not require server-side storage, which is beneficial for scalability.
• Performance: Reduced server load since there is no need for token lookup in a database or session store.
• Flexibility: Can be used for various authentication scenarios, such as Single Sign-On (SSO).

Cons:

• Security: JWT tokens, once issued, are valid until they expire. If a token is compromised, it can be used until it expires unless there's a mechanism to revoke it.
• Size: JWTs can be large, affecting performance over slow network connections.

Use Cases:

• Suitable for simple authentication scenarios where a stateless authentication mechanism is sufficient.
• Ideal for microservices architecture where each service might need to verify the token independently.

OAuth 2

Pros:

• Granular Access Control: OAuth 2 provides fine-grained control over the access to resources using scopes.
• Delegation: Users can grant limited access to their resources without sharing their credentials.
• Industry Standard: Widely adopted and supported by many identity providers and third-party services.

Cons:

• Complexity: More complex to implement and manage compared to JWT.
• Stateful: Typically requires server-side storage of tokens (especially refresh tokens) and session management.
• Overhead: Additional steps and exchanges (authorization code, token exchange) can add overhead.

Use Cases:

• Best suited for applications where you need to delegate access to resources, such as allowing third-party applications to access user data.
• Suitable for complex scenarios requiring fine-grained access control and the ability to revoke tokens.

Recommendation

For FluentCMS with headless features, here are some considerations to help you decide:

1. Complexity of Authentication Requirements:

   • If you need simple, stateless authentication with minimal setup, JWT might be the better choice.
   • If you need to support delegated access, third-party integrations, and granular access control, OAuth 2 is more suitable.

2. Security Considerations:

   • JWTs are stateless and easier to implement but may pose security risks if not managed properly (e.g., token revocation).
   • OAuth 2 provides more robust security features but requires careful implementation and management.

3. Scalability and Performance:

   • JWT offers better performance and scalability due to its stateless nature.
   • OAuth 2 requires additional server-side management, which could introduce some overhead.

[pournasserian]

JWT (JSON Web Tokens)

Pros:

• Simplicity: JWT is straightforward and easy to implement.
• Stateless: Once issued, tokens are self-contained and do not require server-side storage, which is beneficial for scalability.
• Performance: Reduced server load since there is no need for token lookup in a database or session store.
• Flexibility: Can be used for various authentication scenarios, such as Single Sign-On (SSO).

Cons:

• Security: JWT tokens, once issued, are valid until they expire. If a token is compromised, it can be used until it expires unless there's a mechanism to revoke it.
• Size: JWTs can be large, affecting performance over slow network connections.

Use Cases:

• Suitable for simple authentication scenarios where a stateless authentication mechanism is sufficient.
• Ideal for microservices architecture where each service might need to verify the token independently.

OAuth 2

Pros:

• Granular Access Control: OAuth 2 provides fine-grained control over the access to resources using scopes.
• Delegation: Users can grant limited access to their resources without sharing their credentials.
• Industry Standard: Widely adopted and supported by many identity providers and third-party services.

Cons:

• Complexity: More complex to implement and manage compared to JWT.
• Stateful: Typically requires server-side storage of tokens (especially refresh tokens) and session management.
• Overhead: Additional steps and exchanges (authorization code, token exchange) can add overhead.

Use Cases:

• Best suited for applications where you need to delegate access to resources, such as allowing third-party applications to access user data.
• Suitable for complex scenarios requiring fine-grained access control and the ability to revoke tokens.

Recommendation

For FluentCMS with headless features, here are some considerations to help you decide:

1. Complexity of Authentication Requirements:

   • If you need simple, stateless authentication with minimal setup, JWT might be the better choice.
   • If you need to support delegated access, third-party integrations, and granular access control, OAuth 2 is more suitable.

2. Security Considerations:

   • JWTs are stateless and easier to implement but may pose security risks if not managed properly (e.g., token revocation).
   • OAuth 2 provides more robust security features but requires careful implementation and management.

3. Scalability and Performance:

   • JWT offers better performance and scalability due to its stateless nature.
   • OAuth 2 requires additional server-side management, which could introduce some overhead.

Since the identity server won't provide authentication services to external services (only use in the CMS), I prefer to go with JWT (similar solution that we already have). In the meantime, we may change that later upon request (after MVP). The token will be used to call our own apis.

[afsharm]

After discussion we decided to implement it as following:

Each API has an API Key which should be sent as a header with each request. There is no need for a secret key or signing the requests. If needed, it could be done in future.

In the server side the API key should be validated at the nearest place to the actual request. Either it is a middleware or it is an attribute like [Authorize]