067 | Spring Security - OAuth 2.0 Authentication

🎈OAuth 2.0

🧩 OAuth 2.0이란?

• 사용자 정보를 보유하고 있는 신뢰할 만한 써드 파티 애플리케이션(GitHub, Google, 등)에서 사용자의 인증을 대신 처리 → 접근 권한에 대한 토큰 발급 → 해당 토큰을 이용해 써드 파티 애플리케이션의 서비스를 사용하게 해주는 방식이다. 하지만 사용자의 정보가 웹 애플리케이션에 저장되는 것은 변함 없다. Authentication을 다른 서비스에 맡기고 토큰을 받아 올 뿐, Authorizaiton는 여전히 웹 애플리케이션이 관리해야 한다.
• OAuth는 보안된 자신의 리소스에 접근하기 위해 권한을 부여해주는 개방형 표준 프로토콜의 한 종류이다. 대중적으로 많이 사용중인 서비스에서 관리하므로, 사용자 입장에서는 자신의 정보를 노출시키지 않아도 해당 웹 애플리케이션을 사용할 수 있다.

🧩 OAuth 2.0 인증 컴포넌트 역할과 용어

• Resource Owner: 사용할 리소스의 소유자이다.
  • 내가 구글 계정으로 로그인해서 다른 서비스를 이용하고 있다면 내가 구글 서비스 Resource에 대한 Resource Owner가 된다.
• Client: Resource owner를 대신해 보호된 리소스에 액세스하는 애플리케이션이다.
  • 내가 캔디크러쉬사가에서 구글 소셜 로그인을 이용하면 캔디크러쉬사가가 클라이언트이다.
• Resource Server: user의 리소스를 갖고 있는 서버로, Client의 요청을 수락하고 Resource Owner에게 해당하는 리소스를 응답할 수 있는 서버이다.
  • 캔디크러쉬사가가 구글포토에서 내 Resource Owner의 사진(Resource)을 가져오면
    구글포토 서비스 제공 애플리케이션 == Resource Server
• Authorization Server: Client가 Resource Server에 접근할 수 있는 권한을 부여하는 서버이다.
  
  • 내가(Resource Owner) 구글 로그인 인증에 성공하면 캔디크러쉬사가(Client)는 Authorization Server로부터 구글포토에 저장되어 있는 내 사진(Resource)에 접근할 수 있는 권한(Access Token)을 부여받는다.
  • 내가(Resource Owner) 캔디크러쉬사가(Client)를 구글 계정으로 로그인하면
    구글 == Resource Server & Authorization Server
• Authorization Grant: Client가 서버에서 Access Token을 얻기 위한 수단이다.
  • Grant type: 클라이언트가 액세스 토큰을 얻는 방법이다.
  • 종류로는 Authorization Code Grant type, Implicit Grant Type, Client Credentials Grant Type, Resource Owner Credentials Grant Type이 있다.
• Authorization Code: 액세스 토큰을 발급받기 전에 필요한 코드이다.
• Access Token: 보호된 리소스에 액세스하는 데 사용되는 credentials이다. 이 토큰으로 Resource Server에 자원에 접근할 수 있다.
• Scope: 주어진 액세스 토큰의 접근 권한 Scope 내에서만 액세스할 수 있는 리소스의 범위이다.

🎈OAuth 2.0 동작 방식

Authorizsation Grant Type에 따라 인증받는 방법이 다르다.

🧩 Authorisation Grant에 따른 인증 처리 방식

🪄 Authorisation Code Grant

가장 많이 쓰이고 기본이 되는 방식으로, 권한 부여 승인을 위해 자체 생성한 Authorisation Code를 전달한다.

1. Resource Owner는 Client(애플리케이션)에게 서비스 요청을 전송한다.
2. Client는 Authorisation Server에 Authorisation Code를 요청하면서 미리 생성한 Client ID, Redirect URI, 응답 타입을 함께 전송한다.
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행합니다.
4. 로그인이 확인되면 Authorisation Server는 Client에게 Authorisation Code를 전달한다.
   (이 전에 요청과 함께 전달한 Redirect URI로 Code를 전달)
5. Client는 전달받은 Authorisation Code로 Access Token 발급을 요청한다.
   AccessToken을 요청할 때 미리 생성한 Client Secret, Redirect URI, 권한 부여 방식, Authorisation Code를 함께 전송한다.
6. 요청 정보를 확인한 후 Redirect URI로 Access Token을 발급한다.
7. Client는 발급받은 Access Token을 이용해 Resource Server에 Resource를 요청한다.
8. Access Token을 확인한 후 요청 받은 Resource를 Client에게 전달한다.

🪄 Implicit Grant

별도의 Authorisation Code 없이 바로 Access Token을 발급하는 방식으로, 자격증명을 안전하게 저장하기 힘든 Client(스크립트 언어-js-를 사용하는 브라우저)에게 최적화된 방식이다.

1. Resource Owner는 Client(애플리케이션)에게 서비스 요청을 전송한다.
2. Client는 Authorisation Server에게 접근 권한을 요청하며 미리 생성한 Client ID, Redirect URI, 응답타입을 함께 전달한다. (Authroization Code를 획득하기 위한 요청이 아님)
3. Resource Owner는 로그인 페이지를 통해 로그인을 진행한다.
4. 로그인이 확인되면 Authorisation Server는 Client에게 Access Token을 전달한다.
5. Client는 Access Token을 이용해 Resource Server에게 Resource를 요청한다.
6. Access Token을 확인한 후 요청 받은 Resource를 전달한다.

🪄 Resource Owner Password Credential Grant

username, password로 Access Token을 발급받는 방식이다.

1. Resource Owner는 Client(애플리케이션)에게 서비스 요청을 전송한다. 이 때 로그인에 필요한 정보(Username, Password)를 이용한다.
2. Client에서는 Resource Owner에게 전달받은 로그인 정보를 통해 Authorisation Server에 Access Token을 요청하며 미리 생성한 Client ID, 권한 부여 방식, 로그인 정보를 함께 전달한다.
3. 요청과 함께 온 정보들을 확인한 후 Client에게 Access Token을 전달한다.
4. Client는 Access Token을 이용하여 Resource Server에게 Resource를 요청한다.
5. Access Token을 확인한 후 요청 받은 Resource를 전달한다.

🪄 Client Credentials Grant

자격 증명을 안전하게 보관할 수 있는 Client에서만 사용되어야 하며, Refresh Token은 사용 불가하다.

1. Authorisation Server에 Access Token을 요청한다.
2. 요청과 함께 온 정보들을 확인하고 Client에 Access Token을 전달한다.
3. Client는 Access Token을 이용해 Resource Server에 자원 요청을 보낸다.
4. Access Token을 확인하고 요청 받은 자원을 전달한다.