토큰, JWT, 쿠키, 세션, OAuth, OIDC .. 등 인증 인가에 대해서 정리해보자.

HTTP/HTTPS 이외에도 K8S등 에서도 사용이 많이 되어 한꺼번에 정리해보았다.
다만 내용이 다양하여, 자세한 내용은 출처로 들어가서 보는것이 좋다.

HTTP

https://korshika.tistory.com/142?category=974498

https://korshika.tistory.com/143?category=974498

HTTP는 무상태성(stateless), 비 연결성(connectionless) 프로토콜로 누가 요청을 했는지, 인증된 클라이언트인지 확인할수 없다.

---

https://velog.io/@jakeseo_me/%EB%B2%88%EC%97%AD-passport-local%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%98%EB%8A%94-%EB%AA%A8%EB%93%A0-%EA%B2%83

쿠키 방식

쿠키는 클라이언트에 저장되는 key와 value로 이루어진 데이터이다.
인증 유효 시간을 설정할 수 있고 유효 시간이 정해진다면 클라이언트가 종료되어도 쿠키가 유지된다.
서버와 요청 응답으로 인해 쿠키가 저장되면 다음 요청은 쿠키에 담긴 정보를 이용해 참조한다.
그러나 문제점으로 사용자 인증에 대한 정보를 모두 클라이언트가 가지고 있게되므로
http 요청을 탈취당할 경우 쿠키 자체를 탈취당해 사용자 정보를 모두 빼앗길 수 있다.
그래서 쿠키 자체는 보안과는 큰 상관이 없는 장바구니 혹은 자동로그인 설정 등에 이용할 수 있다고 한다.

---

출처: https://blog.lgcns.com/2687

세션 방식

세션은 쿠키를 기반으로 하지만 클라이언트에 저장하는 쿠키와는 다르게 서버에 저장하여 관리한다.
서버에서는 클라이언트를 구별하기 위해 각각의 세션ID를 클라이언트마다 부여하게되며 클라이언트가 종료되기 전까지 유지한다.
클라이언트에 저장하는 쿠키보다는 보안이 좋다.
세션 또한 문제점이 있는데 세션 하이재킹 공격이 가능하니 세션의 유효시간을 만들어 예방할 수 있다.
그리고 세션 저장소를 서버에서 관리하기 때문에 사용자가 많아지면 많아질수록 서버에 걸리는 부하가 증가한다.
동시 접속자가 많아지면 해결할 방법을 찾아야 될것이다.

문제점

세션

사용자가 인증을 할 때, 서버는 이러한 정보를 저장해야 하고 이를 세션(Session)이라고 부른다. 대부분의 경우에는 메모리에 저장하는데, 로그인 중인 사용자가 늘어날 경우에는 서버의 RAM에 부하가 걸리게 된다. 이를 피하기 위해 데이터베이스에 저장을 하기도 하는데, 이러한 방식 역시 데이터베이스에 무리를 줄 수 있다.

확장성

사용자가 늘어나게 되면 더 많은 트래픽을 처리하기 위해 여러 프로세스를 돌리거나 컴퓨터를 추가하는 등 서버를 확장해야 한다. 세션을 사용한다면 세션을 분산시키는 시스템을 설계해야 하지만 이러한 과정은 매우 어렵고 복잡한다.

CORS(Cross-Origin Resource Sharing)

웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

---

토큰(JWT)

토큰은 인증을 위해 사용되는 암호화 된 문자열을 말한다.
JWT는 Json Web Token의 약자이고 인증에 필요한 정보들을 암호화시킨 토큰을 말한다.
세션 방식처럼 토큰 자체를 쿠키에 담아서 보내줄 수도 있고 HTTP 헤더에 담아서 보내줄 수도 있다.

애플리케이션이 실행될 때, JWT를 static 변수와 로컬 스토리지에 저장하게 된다.
static 변수에 저장되는 이유는 HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아서 보내야 하는데, 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문이다.
클라이언트에서 JWT를 포함해 요청을 보내면 서버는 허가된 JWT인지를 검사한다.
또한 로그아웃을 할 경우 로컬 스토리지에 저장된 JWT 데이터를 제거한다.
(실제 서비스의 경우에는 로그아웃 시, 사용했던 토큰을 blacklist라는 DB 테이블에 넣어 해당 토큰의 접근을 막는 작업을 해주어야 한다.)

토큰은 3가지 요소로 구성되어 있다.
Header: 3가지 요소를 암호화할 알고리즘 등과 같은 옵션이 들어간다.
Payload: 유저의 고유 ID 등 인증에 필요한 정보가 들어간다.
Verify Signature: Header, Payload와 Secret Key가 더해져 암호화된다.

Header.PayLoad.VerifySignature로 만들어진다.
Header와 Payload는 누구나 디코딩하여 내용을 확인할 수 있기때문에 유저의 비밀번호 같은 정보는 넣지 않도록 한다.
하지만 Secret Key를 알지 못하면 VerifySignature는 복호화할 수 없다.

그렇기 때문에 토큰을 변조하더라도 VerifySignature가 Payload를 기반으로 암호화 되었기 때문에 유효하지 않은 토큰으로
검증이 가능하다.

토큰은 일단 세션보다 훨씬 간편한다.
세션처럼 별도의 저장소 관리가 필요하지 않고 토큰을 발급 후 클라이언트에게 전송 후 검증하는 과정만 있으면 된다.
그러나 발급된 JWT는 삭제가 불가능하다.
세션 같은 경우에는 악의정으로 사용된다면 해당 세션을 삭제하면 된다.
토큰은 탈취당하게 되면 유효 시간이 종료되기 전까지는 탈취자가 얼마든지 악의적으로 사용이 가능하다.
그래서 Refresh Token이라는 것을 이용해 피해를 조금이라도 줄일 수 있다.

[ 토큰 기반 인증 시스템의 이점 ]

무상태성(Stateless) & 확장성(Scalability)

토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless하며, 클라이언트와 서버의 연결고리가 없기 때문에 확장하기에 매우 적합하다. 만약 사용자 정보가 서버 측 세션에 저장된 경우에 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 해주어야 한다. 하지만 토큰을 사용한다면 어떠한 서버로 요청이 와도 상관이 없다.

보안성

클라이언트가 서버로 요청을 보낼 때 더 이상 쿠키를 전달하지 않으므로, 쿠키 사용에 의한 취약점이 사라지게 된다. 하지만 토큰 환경의 취약점이 존재할 수 있으므로 이에 대비해야 한다.

확장성(Extensibility)

시스템의 확장성을 의미하는 Scalability와 달리 Extensibility는 로그인 정보가 사용되는 분야의 확정을 의미한다. 토큰 기반의 인증 시스템에서는 토큰에 선택적인 권한만 부여하여 발급할 수 있으며 OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.

여러 플랫폼 및 도메인

서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있는데, 애플리케이션과 서비스의 규모가 커지면 여러 디바이스를 호환시키고 더 많은 종류의 서비스를 제공하게 된다. 토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있다. 이런 구조를 통해 assests 파일(Image, html, css, js 등)은 모두 CDN에서 제공하고, 서버 측에서는 API만 다루도록 설게할 수 있다.

[ JWT 단점 및 고려사항 ]

Self-contained:

토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.

Payload 인코딩

페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64로 인코딩 된 것이다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 한다.

Stateless

JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 한다.

Tore Token

토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 한다.

---

https://velog.io/@jakeseo_me/Oauth-2.0%EA%B3%BC-OpenID-Connect-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%A0%95%EB%A6%AC

https://gruuuuu.github.io/security/ssofriends/

OAUTH

OAuth 란?

• Open Authorization 로 다양한 플랫폼에서 권한 부여를 위한 산업 표준 프로토콜이다.
• 타사의 사이트에 대한 접근 권한을 얻고, 그 권한을 이용하여 개발할 수 있도록 도와주는 프레임워크

EX) https://blog.naver.com/pjok1122/221586183453
예를 들어서 설명해보겠습니다.
제가 웹 사이트를 개발하고 있는 개발자라고 가정합시다.
제 웹 사이트에 글을 작성하면 자동으로 그 사람의 구글 캘린더에 기록을 남기도록 하려면 어떻게 해야할까요?
가장 간단한 방법은 사용자에게 Google ID/Password를 얻고, 제 웹사이트에서 Google 인증을 하면 되겠죠.
이 방법이 과연 안전할까요?

1. 내 웹 사이트를 어떻게 신뢰하는가?
2. 유저의 google password를 어떻게 보관할 것인가?

뭐 더 설명할 필요도 없습니다. 그냥 잘못된 방법입니다. 따라서 우리는 다음과 같은 방식을 취합니다.

구글로부터 AccessToken을 발급받고, 그 토큰을 기반으로 원하는 기능을 구현한다.

AccessToken이란, 로그인을 하지 않고 인증을 할 수 있도록 해주는 '토큰' 정도로 생각하시면 됩니다. A 유저가 우리 웹사이트에서 자신의 Google 캘린더에 대한 접근을 허용해준다면, AccessToken에는 해당 정보가 고스란히 남아있습니다. 따라서 그 정보를 토대로 캘린더에 글을 작성하고, 삭제하고 할 수 있게 되는 것이지요.

그렇다면 AccessToken을 어떻게 발급하느냐 하는 문제가 남아있습니다.
AccessToken을 발급받기 위한 일련의 과정을 인터페이스로 정의해둔 것이 바로 OAuth 라는 것입니다.

OAuth 탄생 배경

Oauth 방식이 등장하기 전에 내가 만든 사이트에서 다른 사이트의 리소스를 가져오기 위해서는 다른 사이트의 Id와 Password를 직접 입력을 받아 저장하여 필요할 때마다 불러와서 사용을 해야했다.

위와 같은 방식을 사용하게되면 다음과 같은 문제가 발생한다.

• 사용자 : 내가 만든 사이트에 다른 사이트의 id와 password를 공개하는 것에 대해 신뢰할 수 없다.
• 내가 만든 사이트 : id와 password를 받았기에 보안 문제가 생기는 경우 모든 책임을 져야한다.
• 다른 사이트 ( google, naver ) : 내가 만든 사이트를 신뢰할 수 없다.
• 위와 같은 문제를 해결하기 위해 2006년에 트위터 개발자와 Gnolia의 개발자가 안전한 인증방식에 대한 논의를 하면서 OAuth가 등장했고 2010년에 OAuth1.0이 발표되었다. 현재는 OAuth 1.0a를 거쳐 OAuth2.0이 많이 사용되고 있다.

OAuth2.0 용어

구분	설명	비고
Resource Server (자원 서버)	OAuth2.0 서비스를 제공하고, 자원을 관리하는 서버	페이스북 네이버 구글 등
Authorization Server ( 권한 서버 )	Client가 Resource Server의 서비스를 사용할 수 있게 인증하고 토큰을 발행해주는 서버	페이스북 네이버 구글 등
Resource Owner ( 자원 소유자 )	Resource Server의 계정을 소유하고 있는 사용자	이용자
Client ( 클라이언트 )	Resource Server의 API를 사용하여 데이터를 가져오려고 하는 사이트	쇼핑몰 등
access token(접근 토큰)	자원 서버에 자원을 요청할 수 있는 토큰	유효기간 존재
refresh token(재발급 토큰)	권한 서버에 접근 토큰을 요청할 수 있는 토큰 접근 토큰	유효기간 만료 시 사용

A. Client(클라이언트) 측에서 Resource Owner (자원 소유자)에게 인증방식 4가지 중 하나로 승인을 요청한다.
B. Resource Owner(자원 소유자) 측에서 Client(클라기언트) 측으로 인증 권한을 부여한다.
C. Client(클라이언트)는 부여받은 인증 권한으로 Authorization Server(권한 서버)에 엑세스 토큰을 요청한다.
D. Authorization Server(권한 서버)에서 Client와 부여 받은 인증 권한에 대한 유효성을 검사 후 통과하면 엑세스 토큰을 부여한다.
E. Client(클라이언트)는 받아온 엑세스 토큰을 이용하여 Resource Owner(자원 소유자) 의 Resource(자원)에 접근을 요청한다.
F. Resource Server(자원 서버)는 해당 엑세스 토큰의 유효성을 검사한 후 통과하면 요청에 대한 Resource를 Client에 넘겨준다.

Authorization Code Grant (인가 코드 승인)

• Client가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용
• 리소스 접근을 위해, Authorization Server에서 받은 권한 코드로 리소스에 대한 액세스 토큰을 받는 방식
• 다른 인증 절차에 비해 보안성이 높기에 주로 사용된다.

5. OAuth2.0 인증 방식

설명한 흐름도에서 A ~ B 사이의 인증 방식에는 4가지가 있다.

Implicit Grant (암묵적 승인)

• Authorization Code Grant과 다르게 권한 코드 교환 단계가 있음
• 액세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식

Resource Owner Password (리소스 소유자 암호 자격 승인)

• Client가 암호를 사용하여 액세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식

Client Credentials Grant (클라이언트 자격 승인)

• Client가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식

JWT와 OAuth 2.0의 명확한 차이는 뭘까?

JWT와 OAuth 2.0 둘 다 인증 관점에서 비교하여 생각할 수 있겠지만 서로가 추구하는 목적이 다르다.

OAuth 2.0는 하나의 플랫폼의 권한(아무 의미없는 무작위 문자열 토큰)으로 다양한 플랫폼에서 권한을 행사할 수 있게 해줌으로써 리소스 접근이 가능하게 하는데 목적을 두고있다.

JWT는 Cookie, Session을 대신하여 의미있는 문자열 토큰으로써 권한을 행사할 수 있는 토큰의 한 형식이다. (로그인 세션이나 주고받는 값이 유효한지 검증할 때 주로 쓰인다.)

OAuth 2.0 에서 의미없는 정보를 가지는 토큰이 의미있는 정보를 가져야한다면 두 기술을 혼합하여 access token 을 JWT 형식으로 구현할 수도 있다.

---

OPENID(중요)

https://6991httam.medium.com/oauth%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-openid-8c46a65616e6

OpenID의 풀네임은 사실 OpenID Connect(OIDC)이다. OIDC는 OAuth 2.0 프로토콜의 상위 계층에서 인증을 담당하는 프로토콜이다.
이것은 Client(Third-party APP)가 User의 신원을 검증하도록 해줌과 동시에 기본적인 User정보를 얻을 수 있게 해준다.

OAuth프로토콜을 통해 리소스에 접근하기 위해서는 먼저 인증이 선행되어야 하므로 OIDC가 OAuth의 상위 계층에 위치하게 되는 것이다.

OpenID and OAuth

사실 OAuth를 활용하여 로그인 시스템을 구현하기 위해 자료를 찾던 중, OpenID와 OAuth의 개념이 혼용되어 사용되고 있다는 느낌을 받았다.
하지만 둘은 목적에서 차이를 보인다. OpenID는 인증(Authentication) 자체에 목적을 두고 있는 반면 OAuth는 인증 후 리소스 또는 API를 사용할 권한을 갖는 다는 것에 목적이 있다.
즉, 허가(Authorization)의 목적이라는 것이다.

때문에 OAuth도 권한을 얻기 위한 인증 과정이 존재한다.
아마 이 때문에 둘의 개념이 혼용되는 것이 아닌가 추측이 된다.
실제로 Google ID Platform의 OpenID Connect 서비스는 Google OAuth 2.0 API를 사용할 것을 명시하고 있다.
OAuth API에 OpenID API가 포함되어 있다고 생각하면 될 듯하다. 실제로 그렇기도 하다.

위의 OIDC프로토콜 Flow 통해 인증이 완료되면 ID Token이 발급된다. 일반적으로 Access Token도 함께 발급된다.

ID Token은 JWT형식으로 구성된 End-user의 인증 정보를 담고 있는 보안 토큰이다. 주요 Claim으로는 iss, sub, aud, exp, iat들 이 있으며 각각의 의미는 아래와 같다.(Source: OpenID Connect Core)

iss: ID Token을 발급한 ID Provider(example: Google, Facebook).
sub: Client측에서 End-user를 식별할 수 있는 고유한(unique) 식별자.
aud: ID Token이 어떤 Client를 위해 발급된 것인지.
exp: 만료시점, iat: 발급시점

위에서 언급했듯, OIDC는 OAuth 프로토콜의 인증을 담당하는 layer이다.
즉, OAuth프로토콜 위에서 구현되기 때문에 배포 또한 OAuth인프라와 함께 이루어지는 경우가 대부분이다.
Google OAuth 2.0 API가 OpenID Connect API를 포함하고 있다고 한 것이 그 예시라고 할 수 있겠다.

조금 더 믿을 만한? 정보를 통해 보자면 OAuth.net에서 OAuth를 인증의 수단으로 사용시 발생하는 위험성에 대해 매우 매우 자세하게 기술해 놓았다. 요약하자면

OAuth인증을 통해 얻어지는 액세스 토큰은 user 인증 이후에 발급되기 때문에 인증의 증거로써 간주되기 쉬우나 그 액세스 토큰은 Client(user가 아니라 인증을 요구하는 앱)에 대해 불투명하게(opaque) 설계되었기 때문에 user에 대한 어떠한 정보도 말해주지 않는다. 즉, user를 확인할 수단으로 사용할 수 없다.

또한 OAuth를 통해 발급받은 액세스 토큰을 사용하여 보호된 자원(리소스 또는 API)에 접근하는 것을 인증의 증거로 간주하는 경우가 있으나 이것 또한 잘못된 생각이다. 액세스 토큰은 꼭 인증(authentication)이 이루어져야만 얻을 수 있는 것이 아니기 때문이다. 리프레시 토큰이나 Assertion을 통해 액세스 토큰을 인증없이도 발급이 가능하다.

뿐만 아니라 액세스 토큰은 생명 주기가 있다. 토큰이 만료되는 시간이 있다는 말이다. 더 이상 인증이 필요한 user가 존재하지 않아도 액세스 토큰은 만료되지 않았기 때문에 보호된 자원에 접근할 수 있다. 따라서 보호된 자원에 접근은 인증의 증거가 될 수 없다.

이 외에도 액세스 토큰의 탈취 위험성, 액세스 토큰 Injection, audience를 제한하지 않아 다른 client의 액세스토큰으로 우리의 client(naive client)가 인증된 것처럼 위장하는 위험, 유효하지 않은 user정보 Injection이 존재한다.

위의 위험성들은 모두 OAuth를 인증(authentication, not authorization)의 수단으로 사용하기에 발생하는 것들이다. 설계의 목적에 맞게 OIDC 프로토콜을 따른다면 언급된 위험성들을 해소하며 안전하게 인증할 수 있다.

마지막으로 OAuth는 원래 delegated authorization(권한)을 위해 만들어졌는데 사람들이 authentication(인증)을 하는데도 막 씀.
OAuth는 인증을 하기 위해 만들어진게 아님.
Nate도 OAuth를 인증하는데 쓰지 말라고 함. 결국 OpenID Connect는 인증(authentication)을 위해 만들어진 프로토콜임.

OpenID Connect 특징

OpenID Connect는 다음과 같은 특징을 가지고 있습니다.

1. 상호운용성
   인증 서비스는 기본적으로 다양한 컨슈머 서비스들이 사용할 수 있도록 상호운용성을 반드시 충족해야 합니다. OIDC 또한 표준영역(openid, profile, email, address, phone)에 대해 요청 시 필요한 사용자 정보들을 ID 토큰을 통해 제공할 수 있습니다.

2. 단순성, 모바일 지향 형식
   JSON(Javascript Object Notation) 기반의 REST 친화적인 구조를 채택하여 손쉽게 사용할 수 있습니다.

3. 보안
   ISO/IEC 29115 Entity Authentication Assurance 프레임워크의 레벨 1~4를 선택할 수 있습니다. 레벨이 높을수록 인증 시 PIN과 같은 추가적인 정보를 요구할 수 있습니다. [그림 1]에서 'Sign in with Google'을 통해 인증할 경우 추가적으로 인증번호를 물어오는데 이는 레벨 2를 지정하여 사용하는 것으로 유추됩니다.

4. 유연성
   OP에 직접 요청을 할 수 있는 Normal 타입, JWT를 이용하여 서명된 데이터 소스를 모두 OP를 통해 전달하는 Aggregated 타입, 데이터 소스를 RP(Relying Party)에서 직접 Access 토큰을 사용하여 전달받는 Distributed 타입이 있으며, 이 중 하나가 아닌 여러 타입을 결합한 하이브리드 형태로도 사용할 수 있습니다.

---

추가

Access Token 갱신 OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다.
트위터의 경우에는 Access Token을 만료시키지 않는다. OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

OAuth 2.0, OpenID Connect, SAML의 비교

중요한 것은 이것이 기업에서 사용해야 하는 구조에 대한 문제가 아니라 각 표준의 배포 시기에 대한 문제라는 것입니다. 강력한 인증 솔루션이라면 세 가지 구조를 보호가 필요한 운영에 따라 각각 다른 목적으로 사용합니다.

• OAuth 2.0: 예를 들어 새로운 애플리케이션에 가입하면서 Facebook이나 휴대전화 연락처를 통해 새로운 연락처를 자동으로 제공하는 데 동의했다면 OAuth 2.0을 사용했을 가능성이 높습니다. 이 표준은 안전한 위임 액세스를 제공하기 때문입니다. 다시 말해서 애플리케이션이 자격 증명을 공유하지 않고도 사용자를 대신해 서버에서 리소스에 액세스할 수 있습니다. 이것이 가능한 이유는 아이덴티티 공급업체(IdP)가 사용자의 승인을 받아 타사 애플리케이션에 토큰을 발행할 수 있기 때문입니다.

• OpenID Connect: Google을 사용해 YouTube 등의 애플리케이션에 로그인하거나, Facebook을 사용해 온라인 쇼핑 카트에 로그인한다면 이러한 인증 옵션에 대해 잘 알고 있는 셈입니다. OpenID Connect는 사용자 인증에 사용되는 개방형 표준입니다. IdP가 이 표준을 사용하는 이유는 사용자가 IdP에 로그인한 후 다시 로그인하거나 로그인 정보를 공유하지 않고도 다른 웹사이트와 앱에 액세스할 수 있기 때문입니다.

• SAML: SAML 인증은 다른 곳보다 업무 환경에서 경험했을 가능성이 높습니다. 예를 들어 기업 인트라넷이나 IdP에 로그인한 후 자격 증명을 다시 입력하지 않고도 Salesforce, Box 또는 Workday와 같은 별도의 서비스에 액세스할 수 있기 때문입니다. SAML는 IdP와 서비스 공급업체 사이에서 인증 및 권한 인증 데이터를 교환하는 데 사용되는 XML 기반 표준으로, 사용자의 아이덴티티와 권한을 확인한 후 서비스에 대한 액세스를 허용하거나 거부합니다.

기업은 OAuth 2.0, OpenID, SAML 등의 웹 프레임워크와 프로토콜을 사용해 페더레이션된 아이덴티티를 구조화하여 안전하게 보호합니다. 각 표준의 사용 시점을 파악하는 것은 조직의 데이터를 철저히 보호하기 위한 핵심 단계입니다.

SAML과 오쓰의 차이

오쓰(OAuth)는 2006년부터 구글과 트위터에서 공동으로 개발한 SAML보다 다소 새로운 표준이다. 오쓰는 모바일 플랫폼에서 SAML의 결함을 보완하기 위해 개발됐으며, XML이 아닌 JSON을 기반으로 한다.