기타 인증
OpenID
보안성, 효율성 제고를 위해 URL을 식별자로 사용하는 인증방식
=> 여러 사이트에서 개별적 ID/PW 관리 필요 없어짐.
OpenID 제공 서버에서 사용자 정보를 가지고 사용자가 이용하고자 하는 사이트에서 OpenID 요청시, 바로 확인 및 인증
| Role | Description |
| Relaying Party | 사용자가 요청한 URL을 받아 OpenId Provider와 통신하여 인증 페이지 제공 |
| OpenID Provider | 사용할 URL 알려주는 아이디 발급자, 사용자가 별 |
| Users | OpenID를 발급받아 RP가 제공하는 서비스를 사용하는 사람 |
Pros
- 사용자가 ID 기억할 필요 X
- URL만 따르면 되므로 별도 플러그인 설치 없이 웹 브라우저 상에서 가능
- 서비스 제공자(개발자)가 별도의 보안 모듈을 구현할 필요가 없어짐 (∵ OpenID Provider가 그 역할을 대신함)
Cons
OAuth
Open Authorization 인증 표준방식이 존재하지 않은 점을 보완하기 위해 고안된 프로토콜
Single-Page Application (SPA) 의 경우 위와 같이 Authorization Server가 직접 Access Token을 클라이언트에게 발급한다.
※ 이때, Refresh Token은 함께 반환하지 않는다. (보통 데이터베이스에 보관한다.)
+ SPA가 아닌 경우 Access Token을 Redirect를 통해 발급한다.
OpenID vs OAuth
OpenID -> 사용자를 인증(Authentication) 하기 위한 하나의 아이디를 발급
OAuth -> 인증이 아닌 보호된 자원에 접근하기 위한 '인가(Authorization)' 용도로 사용
Reference
전자인증이용기반 확대를 위한 안전성 기준 연구 - KISA & 순천향대학교, 2011
medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-own-a-beginners-guide-cf7451a16f66
