OAuth, 인증과 인가

OAuth, 인증과 인가에 대해 개발을 하다보면 분명 마주하는 언어지만 정확히 무엇인지 모르고 넘어가는 경우가 많습니다.

오늘은 확실히 그 개념과 과정을 이해하는 시간을 가져보도록 하겠습니다.

 

인증과 인가 (Authentication, Authorization)

인증은 클라이언트(프론트엔드)의 몫이고, 인가는 서버(백엔드)의 몫입니다.

인증은 본인이 누구임을 증명하는 행위고, 인가는 증명된 누군가에게 권한을 부여하는 행위입니다. 

 

OAuth 

OAuth는 Open Authorization 의 줄임말입니다. OAuth에 대해 다음과 같은 설명을 볼 수 있습니다.

• 애플리케이션에 최종 사용자의 보호된 리소스에 대한 액세스 권한을 부여하는 개방형 표준 인증 프레임워크
• 사용자의 비밀번호를 직접 노출하지 않고도 한 애플리케이션이 다른 애플리케이션의 특정 정보에 접근하도록 권한을 부여하는 개방형 표준 프로토콜

즉 '다른 웹 사이트의 회원정보를 이용하여 권한을 부여하기 위한 규약' 이라는 뜻입니다.

 

저희가 직접 로그인, 로그아웃, 회원가입을 위해 로그인 기능 자체를 구현할 필요 없이

'다른 어플리케이션에 가입되어 있는 회원 정보를 그대로 가져와서 사용' 하여 로그인을 구현하는 방법이 OAuth 입니다.

 

인증제공자

인증제공자는 '로그인 하는 곳 (== Authorization Server)' 을 의미합니다. 

예를 들면 구글, 네이버, 카카오가 인증 제공자가 될 수 있겠네요.

 

저희가 만들고 있는 웹사이트를 MyApp이라고 지칭한다고 치면, 저희는 이 MyApp을 인증제공자에 등록해주면 됩니다.

인증제공자에 MyApp을 등록하면, 

1. 인증제공자는 MyApp에 client_id (와 client_secret)을 발급해줍니다.
2. 그럼 서버는 내부적으로 client_id (와 client_secret)를 저장해둡니다. 
3. 또한 인증제공자에 <허용할 Redirect URI 리스트>를 등록합니다. 

참고로 client_secret은 동적인 서버가 존재할 때만 이용하므로 괄호 처리를 해두었습니다. 

 

 

OAuth 2.0 의 증명을 요청하는 과정

OAuth 1.0 과 2.0이 존재하지만 오늘은 2.0을 기준으로 OAuth의 과정을 설명드리겠습니다.

동적인 서버란?  어플리케이션 서버를 의미합니다.

동적인 서버가 존재한다는 것은? HTML을 서빙하는 서버와 API 제공해주는 서버가 동일하다는 것을 의미합니다.

 

동적인 서버라는 것은 정적으로 정해진 응답만을 제공하는 웹 서버가 아니라, 특정 로직을 수행하고 그 로직에 맞게 응답을 생성하여 반환해주는 서버입니다. (물론, 웹 서버든 어플리케이션 서버든 컴퓨터가 켜져있고, CPU가 돌긴 하지만 목적성에 따라 나누었다고 이해하면 됩니다.)

동적인 서버가 존재할 때

1. 인증제공자의 로그인 페이지(ex. 카카오 로그인 페이지)로 이동합니다

• 이때, 쿼리파라미터로 client_id, redirect_uri를 넘깁니다. 

2. 인증제공자에서는 등록된 앱이 맞는지, 유효한 redirect_uri가 맞는지 확인 후 로그인하는 창을 정상적으로 띄워줍니다. (로그인 진행)

3. 유저가 로그인합니다. (이때, 권한 설정도 같이 합니다. - 허용할 권한 선택)

4. 로그인 완료 -> redirect uri로 code를 쿼리파라미터로 담아서 MyApp으로 리다이렉트 해줍니다. 

• 이때, code는 일회용이며 Authorization Code 입니다.

5. redirect uri로 넘어온 MyApp은 내부적으로 저장해둔 client_secret과 Authorization Code를 인증제공자에게 보냅니다.

6. 인증제공자가 다회용 토큰인 Access Token을 발급해줍니다.

 

서버가 존재하지 않을 때 (정적인 SPA 환경)

0. 메모리에 임의의 code_verifier 값을 생성해 저장해둡니다.

1. 인증제공자의 로그인 페이지(ex. 카카오 로그인 페이지)로 이동합니다

• 이때, 쿼리파라미터로 client_id, redirect_uri, code_challange(code_verifier를 해싱한 값) 를 전달합니다. 
• 참고로 해싱하는 방법도 같이 전달합니다. 

2~4. 위의 과정과 동일하므로 생략

5. code_verifier + Authorization Code를 인증제공자에게 보내며 AccessToken을 요청합니다.

6. 인증제공자는 code_verifier로 해싱해보고 code_challange값과 일치하는지 확인합니다. (Auth Code도 같은지 비교)

7. 일치한다면 Access Token을 발급해줍니다.

 

 

마무리

여기까지 OAuth 2.0의 증명 과정에 대해 알아보았습니다. 

 

이 과정을 깊게 이해하다보면, 배포 - 개발 환경에서 동일하게 로그인을 처리하기 위해 Redirect Uri을 분리된 서버에게 보내는 등 적절하게 활용할 수 있습니다. 무엇이 보안의 대상인지, 무엇이 노출되는지 알 수 있으므로 좀 더 유연한 개발이 가능해집니다.

 

 

비고) SSO의 종류로 OAuth(w/ OIDC), SAML이 존재합니다.