|
| 1 | +# Oauth2 인증 과정 |
| 2 | + |
| 3 | +Created by: 이재현 |
| 4 | +Created time: 2023년 8월 3일 오후 9:29 |
| 5 | + |
| 6 | +### 먼저, `인증` 이란? |
| 7 | + |
| 8 | +- 식별 가능한 정보로, 서비스에 등록된 유저의 신원을 입증하는 과정 |
| 9 | + - 사원증을 받은 신입 사원은 회사 건물에 출입할 수 있다. |
| 10 | +- 그 신입 사원은 회사 내 모든 시설에 접근이 가능한가? |
| 11 | + |
| 12 | +### 보안 시설은 `접근 권한` 이 있는 사원만 출입가능 하다. |
| 13 | + |
| 14 | +- 이때, 인증된 사용자에 대하여 자원 접근 권한을 확인하는 것을 `**인가**` 라고 말한다. |
| 15 | + |
| 16 | +<aside> |
| 17 | +📌 **즉, `인증과 인가` 라는 것은 자원을 적절하고 유효한 사용자에게 전달/공개하기 위한 방법을 말한다.** |
| 18 | + |
| 19 | +</aside> |
| 20 | + |
| 21 | +--- |
| 22 | + |
| 23 | +### Web 에서의 `인증(**Authentication**)과 인가(Authorization)` 는..? |
| 24 | + |
| 25 | +1. ****************인증하기 - `Request Header`** |
| 26 | +2. ******************************************인증 상태 유지하기 - `Browser`** |
| 27 | +3. **안전하게 인증하기 - `Server`** |
| 28 | +4. **효율적으로 인증하기 - `Token`** |
| 29 | +5. **다른 채널을 통해 인증하기 - `OAuth`** |
| 30 | + |
| 31 | +--- |
| 32 | + |
| 33 | +### OAuth (Open Authorization )는, |
| 34 | + |
| 35 | +- 다른 웹 사이트 상의 자신들의 정보에 대해 **`접근 권한을 부여`**할 수 있는 공통적인 수단이자 개방형 표준이다. |
| 36 | + - 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신의 정보들에 대해 접근 권한을 부여할 수 있는 공통 수단이다. |
| 37 | + |
| 38 | + |
| 39 | + |
| 40 | +- 위와 같은 소셜 로그인 자체를 OAuth 라고 부르면 잘못된 것이다. |
| 41 | + - 소셜 로그인들이 사용하는 인증 절차를 **`OAuth`** 라고 한다. ✅ |
| 42 | +- 초기 버전인 **`OAuth 1.0`** 은 2010 년에 발표되었다! |
| 43 | + - 당시 OAuth1.0 에는 구조적인 문제들이 존재했고 이들을 개선한 `**OAuth2.0`** 이 많이 사용되고 있다. |
| 44 | + |
| 45 | +--- |
| 46 | + |
| 47 | +### 주요 키워드들, |
| 48 | + |
| 49 | + |
| 50 | + |
| 51 | +- `**Resource Owner`** 은 서비스를 사용하는 User 을 의미한다. |
| 52 | +- **************`Client`** 는 서비스를 의미한다. |
| 53 | +- **********************************`Resource Server`** 는 Google, Facebook, ,Twitter 등 OAuth 를 통한 접근을 지원하는 제공자를 의미한다 |
| 54 | + - 보다 세분화하면 **`Resource Server`** 와 `**Authorization Server`** 으로 나눌 수 있지만 일단 통칭하여 Resource Server 라고 부르겠다. |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +### 소셜 로그인을 사용했던 경험으로 부터, |
| 59 | + |
| 60 | +- 소셜 계정이 존재한다면 원클릭 만으로 인증, 인가가 이루어진다. |
| 61 | + - 👶 사용자 입장에서는, |
| 62 | + `ID` , `Password` 를 넘겨주지 않아도 된다. ✅ |
| 63 | + - 👨💻 서비스 입장에서는 |
| 64 | + `ID` , `Password` 정보를 보관/관리하려 애쓰지 않아도 된다. ✅ |
| 65 | + |
| 66 | +> **즉, OAuth2 는 사용자가 서비스에게 ID, Password 와 같은 개인 정보를 제공하지 않고 원래 가입되어 있던 서비스 제공자의 서비스를 이용할 수 있는 방법을 제공한다.** |
| 67 | +> |
| 68 | + |
| 69 | +### 잠깐, 카카오에서는? (REST API) |
| 70 | + |
| 71 | + |
| 72 | + |
| 73 | +### 복잡해보이지만 차근차근 살펴보면, |
| 74 | + |
| 75 | +### `0. Register` |
| 76 | + |
| 77 | +- Client 는 Resource Server 에 등록 과정을 거친다. |
| 78 | + - Client ID |
| 79 | + - Client Secret |
| 80 | + - Authorized redirect URLs |
| 81 | + - 사용자의 인증이 성공했을 경우 해당 URL 으로 redirect 하여 **`Authorization Code(인증 코드)`** 를 클라이언트에게 전달해준다. |
| 82 | + - 이 인가 코드는 Kakao Auth Server 로 접근할 수 있는 Access token 에 대한 교환권과 같은 개념으로 사용된다. |
| 83 | +- **Q. 인증 코드를 반환하기 보다 그냥 바로 Access token 을 반환하면 안되나요?** |
| 84 | + - Redirect URI 를 통해 데이터를 전달하는 방법은 URI 에 데이터를 실어서 전달하는 방법 밖에 없는데, 이는 브라우저를 통해 쉽게 노출된다는 위험이 있다. |
| 85 | + |
| 86 | + - Access token 을 바로 반환하면, token 탈취 위험이 증가하므로 인가 코드를 반환한 다음 Backend 를 거쳐서 Access token 을 얻어올 수 있도록 구현하는 것이 권장된다. |
| 87 | + |
| 88 | +### `1. Login` |
| 89 | + |
| 90 | +- Client 가 제공한 소셜 로그인 버튼을 통해 Resource Owner 는 OAuth 과정에 진입한다. |
| 91 | +- Auth Server 가 제공한 Login 페이지로부터 사용자는 ID, Password 를 제공한다. |
| 92 | + - Auth Server 내에서 사용자를 인증하고 문제가 없다면 Authorization Code(인증 코드)를 redirect 한다. |
| 93 | +- Front 쪽에서 받은 인증 코드를 Backend 로 넘겨준다. |
| 94 | + |
| 95 | +### ******************`2. Issuse Access Token`****************** |
| 96 | + |
| 97 | +- Backend 에서는 인증 코드를 Auth Server 로 넘겨주며 Access Token 을 요청한다. |
| 98 | +- Auth Server 에서 해당 인증 코드가 유효하다고 판단되면 Access Token 을 Backend 에게 발급해준다. |
| 99 | + |
| 100 | +**이 부분은 구현하기 나름이지만,** |
| 101 | + |
| 102 | +- 받은 Access Token 으로 부터 사용자의 정보를 조회한 다음, 우리 서비스 DB 내에 존재하는 회원인지 확인한다. |
| 103 | + - 존재하지 않는 서비스 신규 회원 가입 절차 |
| 104 | + - 존재한다면 서비스 로그인 절차 |
| 105 | + - 이 부분에서 Access Token / Refresh Token 과 같은 추가적인 구현 사항을 적용할 수도 있다. |
| 106 | +- 이후 자체 Token 을 발급한 뒤 사용자에게 반환해준다. |
| 107 | + |
| 108 | +### `3. Resource request with Token` |
| 109 | + |
| 110 | +- 이제 사용자는 발급받은 Token 을 request Authorization header 필드에 담아서 API 요청을 한다. |
| 111 | +- Backend 에서는 Request header 에 Authorization 필드에 들어있는 token 을 꺼내서 사용자에 대한 인증 인가 작업을 거친 뒤 이상이 없으면 API 를 작동시킨다. |
| 112 | + |
| 113 | +--- |
| 114 | + |
| 115 | +## References |
| 116 | + |
| 117 | +[[10분 테코톡] 🎡토니의 인증과 인가](https://www.youtube.com/watch?v=y0xMXlOAfss) |
| 118 | + |
| 119 | +[OAuth 2.0 설명](https://wordbe.tistory.com/entry/OAuth-20-설명) |
| 120 | + |
| 121 | +[스프링 시큐리티 인 액션 - 예스24](https://www.yes24.com/Product/Goods/112200347) |
0 commit comments