저는 Google OAuth2 서버를 OpenID Connect 제공자로 사용하여 테스트했을 때 잘 작동했습니다.
질문자님이 겪고 계신 문제는 Discourse의 사용자명 제안(username suggester) 코드의 작동 방식과 관련이 있을 것 같습니다. Keycloak은 preferred_username을 반환합니다. 인증 제공자(Identity Provider)에서 반환된 userinfo에 preferred_username이 설정되어 있다면, 이는 name 필드 또는 given_name/family_name 필드의 값보다 우선순위가 높습니다.
참고로, 문제가 발생하는 곳은 다음과 같습니다(preferred_username은 이 메서드가 호출되기 전에 username의 값으로 설정됩니다):
그리고 다음 부분입니다:
preferred_username의 값이 사용자명 제안 코드에 전달되는 첫 번째 인자이므로, 이 값이 사용하게 됩니다. 즉, 이 경우 use_name_for_username_suggestions 설정은 효과를 발휘하지 못합니다. 제 생각에는 이 설정은 인증 제공자로부터 preferred_username이 반환되지 않는 경우를 처리하기 위해 의도된 것으로 보입니다.
Keycloak에서 preferred_username이 Discourse로 전달되는 것을 막을 수 있는 방법이 없다면, 이 문제에 대한 좋은 우회 방법을 찾지 못했습니다.
@simon님, 말씀하신 내용이 맞습니다. 테스트용 Keycloak 인스턴스를 통해 확인해 보았습니다. Keycloak 설정에서 preferred_username을 Discourse로 전달하지 않도록 하면, Discourse의 사용자 이름 제안기에서 실제로 이름과 성이 사용되더군요.
하지만 프로덕션 Keycloak는 이 방식으로 설정할 수 없습니다. 클라이언트 설정이 Discourse 외에도 여러 다른 클라이언트와 공유되고 있기 때문입니다.