Hacker News 의견

• 한 사용자는 회사의 인트라넷에서 OAuth 서버를 구현했음. 다른 팀이 공식 사양을 따르지 않고 로그인 구현을 요청했으며, 결국 비공식적인 OAuth 변형을 만들게 되었음

• OAuth 사용 시 여러 제공자와 이메일 가입 옵션이 있을 때, 이전에 어떤 방법으로 로그인했는지 기억하지 못해 새로운 계정을 실수로 생성하게 되는 경우가 있음

• 1년 전 100개의 인기 API에 대해 OAuth를 구현했으며, 경험은 OP가 설명한 것과 유사했음

• 많은 제공자가 prompt=select_account를 지원하지 않거나 사용자가 로그인할 계정을 선택하도록 요청하지 않음. 이는 OIDC에서 특히 문제임

• AWS와 관련된 버그 보고서를 받았으나 재현할 수 없었고, 해당 섹션을 게시물에서 제거했음. 하지만 일반적인 문제점 체크리스트로 유용할 수 있었음

• 공식적인 테스트 스위트가 있다면 오픈 표준 구현에 도움이 될 것임. 사양을 추적하기 어렵기 때문에 검증할 수 있는 테스트 스위트가 유용할 것임

• Facebook의 문제는 기존 서비스 프레임워크를 사용하여 OAuth2를 코딩했지만 사양에 맞추지 못한 경우로 보임. 스크립팅의 일반적인 문제와 유사함

• 일부 제공자는 사양을 따르지 않고 리프레시 토큰을 위한 별도의 엔드포인트를 선택했음

• OIDC/OAuth 제공자에게 SCIM 지원을 제대로 하고, "API 우선" 사고방식으로 시스템을 설계할 것을 요청함. GNAP로 이동하기 전에 결정 재고 필요함