Ambiguity in the summary related to the test case Testing for Bypassing Authorization Schema

[mojtaba13133]

These 2 lines are mentioned in the summary of the Testing for Bypassing Authorization Schema test case, but the access level has no meaning if the user has no session and no authentication.

1- Is it possible to access that resource even if the user is not authenticated?

2- Is it possible to access that resource after the log-out?

In your opinion, 2 items include Testing for Bypassing Authentication Schema test case?
Please explain to me how access after logout or without authentication can be included in this test case while this test case examines the level of access of authenticated users horizontally and vertically?
This seems to be in conflict with the Direct page request in Testing for Bypassing Authentication Schema

[kingthorin]

Would it be more clear if the first one was: "...user was never authenticated".

[mojtaba13133]

In my opinion, it is still ambiguous with this change because when the user is not authenticated or the user has never been authenticated, it is still included in the Bypassing Authentication Schema test case.

How can a user be given access level without authentication or after logging out? Authorization Schema means when the user is authenticated and has a type of access level, while case 1 and 2 refer to users without authentication and without access level, so it should be tested in the case of Bypassing Authentication Schema because the user can in any way Access resources that only authenticated users should have access to.

Do you agree with the following sentence?
No broken authentication can be broken authorization and no broken authorization can be broken authentication because in broken authentication the level of access (Authorization Schema) has no meaning and in broken authorization there is no meaning in not being authenticated and the users are authenticated.

[ThunderSon]

Hey @mojtaba13133 , thank you for sharing your thoughts on this.
What you're discussing is a piece of the Summary section, and this is not a fully comprehensive list. The Direct page request from the Authentication page you're referencing is a piece of the How to Test section. These two sections are different in behavior.

I don't fully agree with your sentence. Authentication and Authorization aren't necessarily linked to each other. I can give you an API token, not knowing anything about you, as a "user", yet you'd have permissions and access scopes. Authentication concerns itself with identifying who the user is, authorization concerns itself with what permissions does a token/session/whatever has. They live together, separately.

1. This point tackles direct page access, if a developer forgot to put a certain permissions check on the URL. Example: as part of our latest feature, we developed the page /analytics/:id, where :id maps to assets. A check was forgotten, to see if :id belongs to said user, or if the user is an admin that has perms on all analytics.
2. This concerns itself with several points. The main one I'd raise is "how is authorization scopes handled post-logout", what about caching, etc.

I hope this clarifies the matter at hand.
If you want deeper reading on the Authentication/Authorization distinction, check OAuth2 and OIDC, how they're different, and what each aims to do.

[mojtaba13133]

Hey @mojtaba13133 , thank you for sharing your thoughts on this. What you're discussing is a piece of the Summary section, and this is not a fully comprehensive list. The Direct page request from the Authentication page you're referencing is a piece of the How to Test section. These two sections are different in behavior.

I don't fully agree with your sentence. Authentication and Authorization aren't necessarily linked to each other. I can give you an API token, not knowing anything about you, as a "user", yet you'd have permissions and access scopes. Authentication concerns itself with identifying who the user is, authorization concerns itself with what permissions does a token/session/whatever has. They live together, separately.

1. This point tackles direct page access, if a developer forgot to put a certain permissions check on the URL. Example: as part of our latest feature, we developed the page `/analytics/:id`, where `:id` maps to assets. A check was forgotten, to see if `:id` belongs to said user, or if the user is an admin that has perms on all analytics.

2. This concerns itself with several points. The main one I'd raise is "how is authorization scopes handled post-logout", what about caching, etc.

I hope this clarifies the matter at hand. If you want deeper reading on the Authentication/Authorization distinction, check OAuth2 and OIDC, how they're different, and what each aims to do.

I agree with your example. But this case is very special and should not be considered a special case in general.
#1089 (comment)
And my first comment is much more general. I would also like to know your opinion and your reason for which category you fall into