feat: add support to multiple authentication

[yomaaf]

Description

This PR fixes #708

Hello @sansyrox. This is a split PR for support for multiple authentication, however it does not include support for subrouter. Because, as previously explained. When decorating is called, it registers the route. So the authentication handler is not registered on the subrouter because the subrouter already register the route before the authentication handler is registered. I'll include support for the subrouter in the nested router PR. But it will require this PR merge first. So check out this PR first.

[vercel]

@yomaaf is attempting to deploy a commit to the sparckles Team on Vercel.

A member of the Team first needs to authorize it.

[codspeed-hq]

CodSpeed Performance Report

Merging #901 will not alter performance

_{Comparing yomaaf:feature/multiple-authentication (eb30410) with main (1fb2a1f)}

Summary

✅ 110 untouched benchmarks

🆕 16 new benchmarks

Benchmarks breakdown

	Benchmark	main	yomaaf:feature/multiple-authentication	Change
🆕	test_invalid_authentication_header_basic[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_header_basic[sync]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_header_bearer_2[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_header_bearer_2[sync]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_no_token_basic[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_no_token_basic[sync]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_no_token_bearer_2[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_no_token_bearer_2[sync]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_token_basic[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_token_basic[sync]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_token_bearer_2[async]	N/A	4.7 ms	N/A
🆕	test_invalid_authentication_token_bearer_2[sync]	N/A	4.7 ms	N/A
🆕	test_valid_authentication_basic[async]	N/A	4.8 ms	N/A
🆕	test_valid_authentication_basic[sync]	N/A	4.8 ms	N/A
🆕	test_valid_authentication_bearer_2[async]	N/A	4.8 ms	N/A
🆕	test_valid_authentication_bearer_2[sync]	N/A	4.8 ms	N/A

[sansyrox]

Hey @yomaaf 👋

Thanks for the PR. However, I do not understand the problem you are addressing here.

What do you mean by "multiple authentication" and why is it needed in Robyn?

[yomaaf]

Hey @yomaaf 👋

Thanks for the PR. However, I do not understand the problem you are addressing here.

What do you mean by "multiple authentication" and why is it needed in Robyn?

Hi @sansyrox.

"Multiple authentication" refers to the capability of a system to support different methods or mechanisms for verifying the identity of a user. This can include a variety of authentication methods such as:

• Password-based authentication: The most common method, where users authenticate using a username and password.
• Multi-factor authentication (MFA): Requires users to provide two or more verification factors (e.g., password and OTP).
• OAuth: A protocol that allows third-party services to exchange tokens and authenticate users without sharing passwords.

Why is it needed in Robyn?

1. Role-specific Security Requirements:

   • Certain routes, such as those accessible to superadmins, may require more stringent security measures like JWT bearer tokens to ensure high levels of security.
   • Other routes, which may have less critical data, can use simpler authentication methods like password-based authentication.

2. Compliance with Access Control Policies:

   • Different routes may have varying compliance requirements. Supporting multiple authentication handlers allows Robyn to meet these diverse requirements effectively.

3. Flexibility for Different Use Cases:

   • Different applications or user groups may have varying security and usability requirements. Multiple authentication options provide the necessary flexibility to meet these diverse needs.

Addressing fina-joy's Issue #708

While Robyn currently supports middleware for handling authentication at the main router level, there is a growing need for more granular control, specifically at the sub-router level.
This would allow different authentication strategies for different sections of an application, enhancing security and flexibility.

[sansyrox]

Hey @yomaaf 👋

There is only one authentication handler in Robyn so the users can override the implementation. I believe your PR will serve well as a Robyn Plugin like the following - https://robyn.tech/documentation/plugins

However, I don't know enough about auth and need some time to think about it. I will get back to you after the weekend 😄

Meanwhile, if you have any items to help me with my research, I'd highly appreciate them.

Thanks again for all the hard work :D

[user-for-download]

need this functionality)

[JulianDeal]

@sansyrox @yomaaf Right now it's not possible to add authentication to a subrouter (as far as I understand).

So why not make the multi-auth functionality a plugin but keep the changes in the Subrouter class where the auth_required attribute gets added to the endpoint handlers?

[recurseml]

⚠️ Only 5 files will be analyzed due to processing limits.

[recurseml]

The code attempts to call get_credentials() on BasicGetter, but the BasicGetter class only implements get_token() and does not have a get_credentials() method. This will result in an AttributeError when the /sync/auth/basic or /async/auth/basic endpoints are accessed.

---

React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)

[recurseml]

The get_credentials method in BasicGetter attempts to decode the base64 token without first checking if basic_token is None. This will raise a TypeError when basic_token is None (which can happen when get_token() returns None). According to Python's base64 documentation, b64decode requires a non-None input. The code should check if basic_token is None before attempting to decode it.

📚 Relevant Docs

---

React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)

[recurseml]

The code introduces a potentially dangerous pattern by adding get_credentials as a method to BasicGetter without properly implementing it in BearerGetter. Since get_credentials is a newly added method in the TokenGetter base class (an abstract class), all derived classes including BearerGetter must implement it. Currently, BearerGetter does not implement this method, which will lead to AttributeError at runtime when trying to use BearerGetter.

---

React with 👍 to tell me that this comment was useful, or 👎 if not (and I'll stop posting more comments like this in the future)

[recurseml]

😱 Found 3 issues. Time to roll up your sleeves! 😱

[sansyrox]

Thanks @yomaaf — multiple named auth handlers is a feature I want, and the one-default validation in auth_handler_configured() plus the new BasicGetter are nice touches. Two things before this can land: first, name is currently a required positional on AuthenticationHandler.__init__, which breaks every existing Handler(token_getter=...) call — can we default it (e.g. to the class name) so it's backward compatible? Second, main has drifted: add_auth_middleware now takes (endpoint, route_type) for method-aware middleware and the route decorators gained openapi_name/openapi_tags, so this needs a rebase to apply. A clearer error when auth_middleware_name doesn't match any registered handler would also help. The test coverage across basic/bearer is great — once it's rebased and the constructor stays compatible, I'm happy to take it.