A cloud native Identity & Access Proxy / API (IAP) and Access Control Decision API that authenticates, authorizes, and mutates incoming HTTP(s) requests. Inspired by the BeyondCorp / Zero Trust white paper. Written in Go.
Complex matching rules of required_scope consisting of mix of logical ANDs and ORs
The design
We propose a new JWT authenticator configuration - scope_match_multiplicity.
scope_match_multiplicity will control how many matches of required_scope are required. Supported values for scope_match_multiplicity: all , any.
scope_match_multiplicity should be optional and the option all should be its default as it reflects current logic.
all scope match multiplicity option requires all scopes from required_scope to be matched by token scopes.
Example of a match:
"required_scope": ["scope1", "scope2"]
token scopes: "scope1 scope2"
any scope match multiplicity option requires at least one scope from required_scope to be matched by token scopes.
Example of a match:
"required_scope": ["scope1", "scope2"]
token scopes: "scope1"
APIs
No response
Data storage
No response
Code and pseudo-code
No response
Degree of constraint
No response
Alternatives considered
Complex matching rules of required_scope consisting of mix of logical ANDs and ORs
for someone that needs only "OR" or only "AND" matching this will introduce unnecessary complexity
it may require different format of required_scope
Merging scope_strategy and scope_match_multiplicity into one value.
scope_strategy and scope_match_multiplicity control different matters
this config can be used in various combinations so there will be need for a const for each combination e.g. exact_all, exact_any
scope_strategy values are extracted to a separate lib and probably are used in many different apps which we will affect with our changes
A separate field any_scope similar to required_scope for scopes that will require at least one match instead of scope_match_multiplicity.
each scope_match_multiplicity option has to be implemented as a new x_scope field
Preflight checklist
Ory Network Project
No response
Context and scope
Currently all scopes in
required_scope
in JWT authenticator are required to be matched by token scopes.Example of a match: "required_scope": ["scope1", "scope2"] token scopes: "scope1 scope2"
We would like an option so any (at least one) match would be enough.
Example of a match: "required_scope": ["scope1", "scope2"] token scopes: "scope1"
We have started a discussion about it in https://github.com/ory/oathkeeper/discussions/1038.
Goals and non-goals
Goals:
required_scope
Non-goals:
required_scope
consisting of mix of logicalAND
s andOR
sThe design
We propose a new JWT authenticator configuration -
scope_match_multiplicity
.scope_match_multiplicity
will control how many matches ofrequired_scope
are required. Supported values forscope_match_multiplicity
:all
,any
.scope_match_multiplicity
should be optional and the optionall
should be its default as it reflects current logic.all
scope match multiplicity option requires all scopes fromrequired_scope
to be matched by token scopes. Example of a match: "required_scope": ["scope1", "scope2"] token scopes: "scope1 scope2"any
scope match multiplicity option requires at least one scope fromrequired_scope
to be matched by token scopes. Example of a match: "required_scope": ["scope1", "scope2"] token scopes: "scope1"APIs
No response
Data storage
No response
Code and pseudo-code
No response
Degree of constraint
No response
Alternatives considered
Complex matching rules of
required_scope
consisting of mix of logicalAND
s andOR
srequired_scope
Merging
scope_strategy
andscope_match_multiplicity
into one value.scope_strategy
andscope_match_multiplicity
control different mattersA separate field
any_scope
similar torequired_scope
for scopes that will require at least one match instead ofscope_match_multiplicity
.scope_match_multiplicity
option has to be implemented as a newx_scope
field