Incorrect Handling of Scopes with Special Character "|" in scp Claim

[Ajayn84]

Preflight checklist

• [X] I could not find a solution in the existing issues, docs, nor discussions.
• [X] I agree to follow this project's Code of Conduct.
• [X] I have read and am following this repository's Contribution Guidelines.
• [x] I have joined the Ory Community Slack.
• [x] I am signed up to the Ory Security Patch Newsletter.

Ory Network Project

No response

Describe the bug

When using a scope that includes the special character "|" (e.g., A|B), we expect the scp claim in the access token to contain the scope as a single string, i.e.,["A|B"]. However, the actual result is that the scope is split into separate elements, resulting in ["A", "B"] Note: The scopes in the access token are returned fine i.e as ["A|B"] for client credentails grant type. But when the grant type is "authorization_code" and there is a consent flow involved, it gives scope in access token as ["A", "B"]

Reproducing the bug

1. Create a client having scope with the special character "|", such as "A|B".
2. Perform oauth2 login with hydra , which involves consent flow
3. Request an access token with this scope.
4. Inspect the scp claim in the generated access token.

Relevant log output

No response

Relevant configuration

No response

Version

2.2

On which operating system are you observing this issue?

None

In which environment are you deploying?

Docker

Additional Context

Looking at the scopes stored in hydra_client table, the scopes are stored space separated, but in hydra_oauth2_access table these are stored using "|", might be resulting into this issue

[Ajayn84]

After a bit of digging, have found the issue to be during persisting the scopes in some tables we are using "|" (pipe) as the delimiter. below are the code references https://github.com/ory/hydra/blob/f83193f90814691d10d88493eb6357cf37565115/persistence/sql/persister_oauth2.go#L113 and https://github.com/ory/hydra/blob/f83193f90814691d10d88493eb6357cf37565115/persistence/sql/persister_oauth2.go#L161

If we escape and unescape using some logic like below , then it might resolve this issue

[Ajayn84]

Based on inputs from slack channel from @tacurran ,have used url escape and unescape, which does resolve the issue