Oauth2.0 정리

Oauth란?

Oauth 의 의미를 풀어보면 Open Authentication(인증), Open Authorization(인가) 으로 인증과 인가를 개방한다 정도로 해석할 수 있습니다.

Oauth는 리소스서버에 있는 사용자의 권한을 획득할 수 있도록 합니다. 즉, 인증과 인가를 위한 개방형 표준 인터넷 프로토콜 입니다.

쉽게 말하면 우리의 웹 애플리케이션에서 구글 캘린더에 접근하거나 페이스북에 접근하여 사용자에게 편리한 경험을 주려고 합니다.

이 때 우리는 Oauth를 사용해서 우리 웹 애플리케이션의 사용자가 구글이나 페이스북과 같은 리소스 서버에 인증 또는 인가를 하도록 할 수 있습니다. (이전에는 Oauth가 단순히 로그인만을 위한것이라 생각했습니다 ㅠㅠ)

---

소셜 로그인으로 사용하는 Oauth

Oauth를 사용하기 이전에는 웹 애플리케이션 서버에서 사용자의 정보와 비밀번호를 이용해 권한을 부여했습니다.

비밀번호를 그대로 데이터베이스에 저장한다면 큰 위험이 있기때문에 비밀번호를 암호화하는 과정은 필수였습니다.

또한 애플리케이션이 안전하다는 보장도 없기때문에 비밀번호를 선뜻 제공하기가 꺼려집니다. 사용자는 애플리케이션을 사용하려면 애플리케이션의 보안을 그저 믿고 사용할 수 밖에 없습니다.

이런 번거로움들이 Oauth 로 인해 해소됐습니다.

 

Oauth를 사용하면 구글, 페이스북, 카카오, 네이버 등등의 서비스 제공자에게 인증을 요청해서 토큰을 발급받습니다.

즉, 비밀번호의 암호화 같은 보안을 위한 복잡한 과정은 서비스 제공자에게 맡기고 액세스 토큰을 이용해서 사용자 정보만을 가져올 수 있습니다. 

이로인해 사용자는 간단하게 인증,인가를 받을 수 있고 개발자는 회원가입,로그인에서 보안에 신경써야할 비용이 낮아지고 비즈니스 로직에 더욱 집중할 수 있게됩니다.

---

Oauth2.0 의 특징

• 웹 애플리케이션이 아닌 애플리케이션 지원 강화 (Oauth1.0은 애플리케이션에서 사용하기가 힘들었습니다.)
• 암호화가 필요 없음 HTTPS를 사용하고 HMAC을 사용하지 않습니다.
  • 즉, 암호화는 HTTPS에게 맡기는 것입니다.
• Signature 단순화 정렬과 URL 인코딩이 필요 없습니다.
• Access Token 갱신
  • OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었습니다.(만료시간이 없다)
  •  OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

---

Oauth2.0의 용어

Resource Server : Client가 원하는 자원을 가진 서버입니다. 구글, 페이스북, 카카오, 네이버 등등 소셜로그인을 지원하는 서버를 의미합니다.

 

Client : Resouce Server 에서 자원을 가져오고자 하는 손님, 즉 우리의 애플리케이션을 의미합니다.

 

Resource Owner : 자원의 소유자 입니다. 서비스를 사용하는 사용자라고 생각하면 됩니다!

 

---

Oauth2.0 사용 흐름

Oauth2.0은 다음과 같은 흐름으로 사용됩니다.

 

1. 우선 Resource Server 로 가서 Client(내 Application)을 등록하고 Client ID 와 Client Secret을 발급받습니다.

• Client ID : Client에 대한 식별자입니다. Client Application에 대한 식별자라고 생각하시면 됩니다. 
• Client Secret : Client ID에 대한 비밀번호 입니다. 비밀번호인 만큼 외부에 노출되어선 안되는 중요한 정보입니다.

이후 Client ID와 Client Secret 을 이용해서 Access Token 을 받아올것입니다.

github oauth application 등록

발급받은 github client id, client secret

2. Resource Owner에게 Client가 Resource Server로 접근권한 제공에 동의하는지 질의를 거치고 Authorization Code 응답받기

• Resource Owner가 Oauth가 필요한 서비스를 활용하려면 Resource Owner가 Resource Server에 로그인 요청을 하고 로그인을 완료하면 Client에게 Resource 접근권한을 제공하는것에 동의하는지 물어봅니다.
• Resource Owner가 Resource 접근 권한을 Client Server에게 제공하는데 동의했다면 Client는 Client ID, Redirect URI등 파라미터에 포함하여 요청합니다.
• Resource Server는 Client ID와 Redirect URI를 검사하여 Authorization Code값을 응답합니다. 

예를들어 설명하면 아래와 같습니다.

1. 게임 커뮤니티 서비스의 사용자가 Kakao 소셜 로그인을 사용하려고 합니다.
2. 사용자는 Kakao 로그인 페이지로 이동되며 회원임을 인증하고 사용하고있는 게임 커뮤니티 서비스에 접근권한을 제공할 것인지 물어봅니다.
3. 접근권한 제공에 동의한다면 Resource Server는 Client ID, Redirect URI 등이 일치하는지 검사하고 Authorization Code를 Client에게 제공합니다.

3.Client는 Resource Server에서 Resource 접근 권한이 있는 Access Token을 받급받습니다.

• Client는 Authorization Code, Client ID, Client Secret과 함께 Resource Server에 Access Token 발급 요청을 보냅니다.
• Resource Server는 요청으로 온 Client ID, Cliend Secret, Authorization Code가 유효하다면 Access Token을 Client에게 발급합습니다.

4. Client 는 Resource Server에게 Access Token을 이용해서 접근 권한이 있는 Resource를 요청하고 받을 수 있습니다.

 

---

Grant Type

Oauth2.0은 다양한 클라이언트 환경에 적합한 인증, 인가 위임 방식을 제공합니다.

위에서 설명드린 방식은 웹 애플리케이션에서 흔히 사용하는 방식인 Authorization Code 입니다.

 

Grant Type에는 4가지가 있습니다.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

Grant Type에 대한 자세한 내용은 이 글을 참고해주세요!

---

참고자료

• https://velog.io/@mu1616/OAuth2.0-%EC%9D%B8%EC%A6%9D-%EA%B3%BC%EC%A0%95
• https://woowacourse.github.io/tecoble/post/2021-07-10-understanding-oauth/
• https://baked-corn.tistory.com/29
• https://oauth.net/2/