▲

GN⁺: OAuth 제공자에게 보내는 편지

 (pilcrowonpaper.com)
1P by neo 15일전 | favorite | 댓글 2개

  • OAuth 공급자에게 보내는 편지

    • GitHub

      • 토큰 엔드포인트가 오류에도 200 상태 코드를 반환함
      • 오류 응답은 400 또는 401 상태 코드를 사용해야 함

    • Facebook

      • 토큰 엔드포인트가 사용자 정의 오류 응답을 반환함
      • 오류 필드가 있는 JSON 객체여야 함

    • TikTok

      • 서버가 client_id 대신 client_key 매개변수를 사용함
      • 사양에서 벗어난 이유가 없음

    • Strava

      • 서버가 범위 매개변수에 쉼표로 구분된 목록을 사용함
      • 공백으로 구분된 목록이어야 함

    • Naver

      • 서버가 토큰 만료 시간을 문자열로 반환함
      • 사양 준수 여부를 넘어선 문제임

    • 다양한 OAuth 공급자

      • 클라이언트 인증을 위해 client_secret 매개변수 대신 HTTP 기본 인증을 지원해야 함
      • OAuth 2.1 표준에서 HTTP 기본 인증은 선택 사항이지만, PKCE가 요구됨에도 불구하고 대부분의 공급자가 이를 사용하지 않음

    • AWS

      • OAuth 클라이언트 라이브러리와 함께 사용 시 여러 버그 보고를 받았으나, 문제를 재현할 수 없어 관련 내용을 삭제함
▲
rikko 15일전  [-]

정부 대국민 서비스 프로젝트 구축하면서, OAuth (OIDC) 기능 구현에만 1달이 꼬박 걸린 경험이 있습니다...

외부 라이브러리를 쓸 수 없다보니, 일일히 다 구현해야 했는데 OAuth 표준을 제대로 지키는건 카카오나 구글 말고는 없었습니다...

네이버는 뭐, 로그인만 되면 문제 없지 수준이라 써도 되나 싶었고, 애플은 지금 생각해도 어떻게 구현했는지 기억조차 안날 정도로 기존 Oauth 소스의 3배 이상의 구현 코드가 필요했습니다.

위 본문처럼 응답 코드가 개판인 경우도 있고, 하다하다 418(I'm a teapot) 을 회신하는 제공자도 있었죠.
이런 경험이 있다보니 저는 소셜로그인 같은 기능을 편해도 안쓰게 되더랍니다...

답변달기
▲
neo 15일전  [-]
Hacker News 의견

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

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

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

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

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

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

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

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

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

답변달기