Oauth에 대해서 정리

참조: http://blog.weirdx.io/post/39955

OAuth를 구성하고 있는 주요 4가지 객체(Roles)

• resource owner(자원 소유자)는 protected resource(보호된 자원)에 접근하는 권한을 제공합니다.
• resource server(자원 서버)는 access token을 사용해서 요청(request)을 수신할 때, 권한을 검증한 후 적절한 결과를 응답합니다.
• client(클라이언트)는 resource owner(자원 소유자)의 protected resource(보호된 자원)에 접근을 요청을 하는 애플리케이션(application)입니다.
• authorization Server(권한 서버)는 client(클라이언트)가 성공적으로 access token을 발급받은 이후에 resource owner(자원 소유자)를 인증하고 obtaining authorization(권한 부여)를 합니다.

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Authrization Grant Type?

• Authorization Code는 Client(클라이언트)가 Resource Owner(자원 소유자)에게 직접 권한 부여를 요청하는 대신, Resource Owner(자원 소유자)가 Authorization Server(권한 서버)에서 인증을 받고 권한을 허가 합니다. 소유자가 권한을 허가하게 되면 Authorization Code(권한 코드)가 발급되고, 이 Authorization Code(권한 코드)를 클라이언트에게 전달하게 됩니다. 클라이언트는 이 코드를 권한 서버에 보내주면서 자신이 권한 허가를 받았다는 사실을 알리고 access token을 받게 됩니다. 이 방법은 보안상 이점이 있습니다. access token을 바로 Client(클라이언트)로 곧바로 전달하지 않기 때문에 전달과정에서 생길 수 있는 잠재적인 유출 위험을 방지하는데 도움을 줍니다.
• Implicit는 Authorization Code(권한 코드)를 간소화한 절차입니다. Authorization Code(권한 코드) 방식에서 access token을 얻기 위한 중간 매개체로 Authorization Code(권한 코드)를 사용했던 것과 달리, 이 방식은 Authorization Code(권한 코드)가 별도로 발급되지 않고 access token이 바로 발급됩니다. 과정이 줄어들어 편해지는 대신 보안성은 낮아집니다.
• Resource Owner Password Credentials 이 방식에서는 자원 소유자의 계정 아이디와 비밀번호 같은 계정 인증 정보가 access token을 얻기 위한 Authorization Grant(권한 증서)로 사용됩니다. 계정정보를 애플리케이션에 직접 입력해야 하므로, 신뢰할 수 있어야 합니다. access token 을 얻은 후에는 리소스 요청을 위해 계정 아이디, 비밀번호를 Client(클라이언트)가 보관하고 있을 필요는 없습니다.
• Client Credentials 이 방식은 클라이언트 인증 방식이라고도 합니다. 자원 소유자가 유저가 아닌, 클라이언트인 상황에서 활용되는 방식입니다. Client(클라이언트)가 관리하는 리소스에만 접근할 경우로 권한이 한정되어 있을 때 활용할 수 있습니다. 즉 Client(클라이언트)가 곧 Resource Owner(자원 소유자)가 되는 상황입니다. Client(클라이언트)는 자기를 인증할 수 있는 정보를 Authorization Server(권한 서버)에 보내면서 access token을 요청하게 됩니다.

요점 정리

1. session, cookie가 필요하지 않다.

2. client가 요청하면 Authorization Server에서 유효성을 확인 후, access Token값을 준다.

3. access token값으로 필요한 리소스를 조회할 수 있다.