I am able to generate perpetual refresh tokens using legacy username/password authentication and without use of any 2FA:
$ curl -s -X POST 'https://servercontrolpanel.de/realms/scp/protocol/openid-connect/token' \
-d 'client_id=scp' \
-d 'grant_type=password' \
-d 'username=<customer number>' \
-d 'password=<number>' \
-d 'scope=offline_access openid' | jq
{
"access_token": "...",
"expires_in": 300,
"refresh_expires_in": 0,
"refresh_token": "...",
"token_type": "Bearer",
"id_token": "...",
"not-before-policy": 0,
"session_state": "...",
"scope": "openid profile offline_access email"
}OAuth 2.1 does not have this grant type, and OAuth 2.0 Security BCP (Best Current Practice) disallows password grants:
2.4. Resource Owner Password Credentials Grant
The resource owner password credentials grant [RFC6749] MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, usage of this grant results in an increased attack surface (i.e., credentials can leak in more places than just the authorization server) and in training users to enter their credentials in places other than the authorization server.
Furthermore, the resource owner password credentials grant is not designed to work with two-factor authentication and authentication processes that require multiple user interaction steps. Authentication with cryptographic credentials (cf. WebCrypto [W3C.WebCrypto], WebAuthn [W3C.WebAuthn]) may be impossible to implement with this grant type, as it is usually bound to a specific web origin.
In addition, while reviewing the OIDC configuration, there were several other "MUST" violations as well as some other settings that should follow the "SHOULD" recommendations. It may be worth performing a compliance review of your configuration against the security BCP. Issues that I immediately see:
- PKCE `plain` method exposes verifier, PKCE is optional and not mandatory
- `implicit` grants