[TIL] OAuth 2.0

❓ OAuth 2.0 이란?

• 각종 웹이나 애플리케이션에서 타사의 API를 사용하고 싶을 때, 인증과 권한을 획득하는 프로토콜이다.

• 간단하게 말하자면, 로그인에서부터 각종 API를 보다 안전하고 편하게 사용하게 해줄 수 있다.

• OAuth 2.0은 OAuth 1.0의 단점을 보완해서 업데이트 된 버전이라고 볼 수 있다.

🟢 장점이 뭔데?

1) 이용하려는 서비스마다 회원가입을 할 필요 없이 기존의 사용하던 타사의 정보를 이용해서 로그인을 진행할 수 있다는 점,
2) 정보는 회원정보 뿐만 아니라 기타 API에 대한 정보에도 접근이 가능하다는 점

그 중 가장 많이 이용되는 곳이 바로 타사의 인증된 회원정보를 통한 로그인이다.

📌 Authentication (인증) - 신원을 확인하는 것

• 자신이 A라고 하는 개인이 과연 정말로 A가 맞는건지 신원을 확인하는 행위를 의미함 (인증이 됨으로써 어떠한 상태에 변화가 생기는 것은 아님)
• 인증을 함으로써 A라는 사람의 신원이 확인됨 => A가 소유한 특정 자원에 대한 주권을 행사할 수 있게 되지만, 이 주권은 원래부터 A가 가지고 있던 것
• 다시말해, A라는 사람을 인증함으로써 이전에 없던 주권이 새로 생기지는 않는다는 뜻

📌 Authorization (승인) - 권한을 확인하는 것

• 인증이 되기 전과 후, 인증을 수행한 측이나 인증대상의 상태에는 아무런 변화가 없음 (인증 전에 없던 자격이 인증 후에 생기지 않는다는 의미)
• BUT, Authorization(승인)은 이전 상태와 다른 새로운 상태가 됨. why? 승인 받은 대상은 새로운 자격이 생기기 때문

나는..

우리 프로젝트 서비스에서 Oauth 2.0과 passport를 사용하면서 아직 Oauth에 대한 개념이 확실하게 잡히지 않은 것 같아 Oauth의 개념을 우리 프로젝트에 적용해보면서 정리해보기로 했다.

🛠 Oauth 2.0의 4가지 구성

🔻 Client (pillnuts)

• 사용자 데이터를 활용하여 서비스를 제공하려는 응용프로그램
• Client가 사용자 데이터에 접근할 권한을 요청하면서 Oauth2의 절차적 흐름이 시작되고, Client가 사용자 데이터를 받게 되면 끝이 난다.

🔻 Resource Server (Google, Apple, Kakao)

• 데이터를 보유하고 있다는 역할보다는 접근 요청의 유효성을 분별하여 유저가 동의한 Client에게만 데이터를 제공하는 역할임

🔻 Authorization Server

• User 데이터에 접근한 권한을 제공하는 서버

• Client의 접근 요청에 따라, User에게 Client에 대한 등록된 정보 및 Client가 요청한 데이터 항목, 활용하려는 목적 및 기간 등에 대한 정보를 제시하고, user의 동의 여부를 묻는 역할

• 소규모 시스템일 경우, 하나의 개체가 Resource Server/ Authorization Server의 2가지 역할을 수행하는 경우도 있으나,
  규모가 클수록 분리해서 구현하는 경우가 많음

🔻Resource Owner (User)

• Oauth 2.0의 최고 권력자
• Resource Server 입장: 데이터 보호를 부탁한 고객
• Client 입장: 가치를 창출하기 위해 필요한 데이터의 주인
• Resource Owner는 임의로 자신의 데이터에 대한 접근 권한을 부여, 거부 또는 철회할 수 있는 데이터의 주체임
• 아울러, 유저는 제공할 데이터의 범위 및 기간 등에 대한 결정도 내릴 수 있음

💾 OAuth 2.0에 사용되는 데이터

1. Client의 등록 정보

• Oauth 2.0이 작동하기 위해 Client는 사전에 Resource Server에 등록해야 한다.
• 웹페이지 같은 경우, 반드시 Redirect URI에 대한 정보를 등록해야함

2. Redirect URI

• Resource Server는 유저가 Client에게 권한 부여하는 것에 유저가 동의 하면, 유저를 Client에 등록된 Redirect URI로 이동(redirection) 시킨다.
• 만약 등록되지 않은 Redirect URI를 담은 요청을 받게 되면 그 요청은 무효처리가 됨
• 기존에 등록된 Redirect URI의 범위 한해서 유저를 연결시킴으로써 방지할 수 있는 공격들이 있기 때문

3. Client ID와 Client Secret

• 새로 등록한 앱은 Resource Server로부터 ClientId와 Client Secert을 발급받는다.
• Client ID는 공개하는 정보로서 로그인 웹페이지 또는 JS에 포함될 수 있는 정보이다. 반면에, Client Secret은 노출이 되면 안되는 정보이다. 그래서 Client Secret 관리를 잘 해야한다.