1. Authorization Code

    → Owner가 Client에게 인증을 하지 않고 Auth Server에 간접적으로 인증하는 방식 Owner가 Auth Server에 직접 허가한 뒤, Auth Server는 임시코드를 발급한다. Owner는 이 임시코드를 Client에게 제출하고 이것을 Client는 다시 Auth Server에 제출한다. 이로써 인증이 완료되고 이때 임시 코드를 Authorization Code라 한다. 이후 Access Token이 발급된다

    → 장점: Client의 인증뿐만 아니라 외부에 Access Token이 노출없이 전달이 가능하다.

  2. Implicit

    → Authorization Code를 약식화한 버전이다. 스크립트 언어를 활용하는 In-Browser App형태의 Client에서 주로 사용한다. 1번의 과정에서 Authorization Code를 주지 않고 바로 Access Token을 발급한다. Client의 인증이 이뤄지지 않고, Access Token이 노출될 수 있는 위험이 있다.

    →하지만 절차가 간단하며, redirect uri방식을 지원하는 경우도 있다.

  3. Resource Owner Password Credentials

    → Owner의 비밀번호가 Authorization Code가 되어 바로 Access Token을 얻는 방식이다. Owner와 Client간의 신뢰가 높을 경우 주로 사용한다. 그래서 보통 모바일 os같이 접근이 제한된 경우에 주로 사용한다. Owner의 정보를 Client 가 직접 다루기 때문에 다른 인증방법이 불가할 경우에 사용

  4. Client Credentials

    → Client가 소유하고 있는 정보 그 자체로 인증이 이뤄진다. 주로 Client가 Resource Server의 역할을 하거나 인증이 된 경우에 사용된다.