인증 처리에 관한 몇가지

2019, Oct 23    

책을 읽던 중에 평소에 정리할 필요가 있다고 생각했던 부분이 나와서 기록해 둔다.

싱글 사인 온

여러 인증 프로세스의 변형 중 하나로 싱글 사이온(Single Sign-On)이 있다.
싱글 사인온은 샘엘(Security Assertion Markup Language, SAML) 또는 Central Authentication Service(CAS)와
같은 프로토콜을 사용한다. 싱글 사인 온을 사용하면

  • application이 사용자를 아이덴티티 서버(identity server)로 리다이렉트 시키고
  • 인증을 수행하기 위해 identity server에 응답하고 나서 인증 결과를 application에 알려준다.
  • 샘엘을 활용하면 서비스 제공자(Service Provider, SP)인 애플리케이션은 인증 후에
  • 샘엘 어설션(SAML assertion)을 인증 제공자(identity provider, IdP)인 아이덴티티 서버로 부터 받는다.

OAuth 2.0

  • OAuth 2.0 프로토콜은 서드 파티 서비스(third-party service)가 사용자 데이터에 접근할 때 권한을 부여하기 위해 디자인 됐다.
  • 하지만 OAuth 2.0 프로토콜은 사용자를 인증하는 방법으로 매우 유명하다.
  • OAuth 2.0 프로토콜은 네 개의 당사자가 관련된다.
    • 리소스 소유자 : 리소스 서버에 있는 데이터를 소유한 사람. 예를 들어서 나는 트위터에 있는 내 데이터의 소유자다.
    • 리소스 서버 : 클라이언트가 접근하기를 원하는 데이터를 저장하는 서버. 예를 들어 트위터 API 서버는 리소스 서버다.
    • 권한 부여 서버 : 클라이언트가 요청한 데이터로 접근할 수 있도록 권한 부여를 수행하는 서버. 보통 리소스 서버와 권한 부여 서버는 같다.
    • 클라이언트 : 데이터에 접근하기를 원하는 애플리케이션.

OAuth 2.0 인증 흐름 기술

  • 다음은 OAuth 2.0을 활용해서 깃 허브를 통해 애플리케이션에 로그인 할 때의 인증 흐름을 기술 한 것이다.
    • gitHub에 계정이 있는 사용자(리소스 소유자)가 TaskAgile application(클라이언트)에 로그인 하고자 한다.
    • TaskAgile application(클라이언트)은 github 으로 부터 인증결과를 받기 위해 사용자를 깃허브(리소스 서버) 로그인 페이지로 리다이렉트 한다.
    • 사용자가 깃허브에 로그인이 성공하면 권한 부여 코드와 함께 TaskAgile application 으로 리다이렉트
    • TaskAgile application(client)는 깃허브(권한 부여 서버)에 권한 부여 코드를 재사용할 수 있는 액세스 토큰과 교환 요청을 한다.
    • 깃허브 -> Task Agile application 으로 액세스 토큰을 반환한다.
    • Task Agile application -> 깃허브(리소스 서버)로 사용자 정보를 위한 API를 요청
    • 깃허브(리소스 서버) -> Task Agile application 으로 사용자 데이터 반환
    • Task Agile application은 사용자 데이터를 로컬에 저장하고 사용자를 인증된 사용자로 표시한다.

Oauth 2.0 인증 흐름 다이어 그램

  • Oauth 2.0 인증 처리 다이어 그램이다. (직접 그리려다가 너무 잘 정리해 놓은 이미지가 있어 참조 한다. 출처는 아래 링크)
  • 참고(https://bravenamme.github.io/files/posts/201910/1025_auth_flow.png)
Twitter Facebook Google+