출처 : https://fusionauth.io/learn/expert-advice/oauth/differences-between-oauth-2-oauth-2-1/
OAuth 2.1 is consolidating best practices learned over the eight years since Oauth 2 was published. The original OAuth 2.0 specification was released in October 2012 as RFC 6749 and RFC 6750. It replaced OAuth 1.0, released in April 2010. There have been a number of extensions and modifications to OAuth 2 over the subsequent years.
OAuth 2.1은 Oauth 2가 게시된 이후 8년 동안 학습된 모범 사례를 통합하고 있습니다. 원래 OAuth 2.0 사양은 2012년 10월에 RFC 6749 및 RFC 6750으로 출시되었습니다. 이 사양은 2010년 4월에 출시된 OAuth 1.0을 대체했습니다. 이후 몇 년 동안 OAuth 2에 대한 많은 확장과 수정이 있었습니다.
A new OAuth specification has been proposed and is currently under discussion. At this time, the specification was most recently updated on July 30, 2020. If approved, OAuth 2.1 will obsolete certain parts of Oauth 2.0 and mandate security best practices. The rest of the OAuth 2.0 specification will be retained.
새로운 OAuth 사양이 제안되었으며 현재 논의 중입니다. 현재 사양은 2020년 7월 30일에 가장 최근에 업데이트되었습니다. 승인되면 OAuth 2.1은 Oauth 2.0의 특정 부분을 폐기하고 보안 모범 사례를 의무화합니다. 나머지 OAuth 2.0 사양은 유지됩니다.
That bears repeating. Nothing new will be added. This is an explicit design goal of OAuth 2.1.
그것은 반복을 참는다. 새로운 것은 추가되지 않습니다. 이것은 OAuth 2.1의 명시적인 설계 목표입니다.
This article assumes you are a developer or have analogous technical experience and are familiar with OAuth and the terms used in the various corresponding standards. If you’d like an introduction to OAuth and why you’d consider using it, Wikipedia is a good place to start. This article covers proposed changes to OAuth that might affect you if you are either using OAuth in your application or if you build software which implements OAuth.
이 문서에서는 개발자이거나 유사한 기술 경험이 있고 OAuth 및 다양한 해당 표준에서 사용되는 용어에 익숙하다고 가정합니다. OAuth에 대한 소개와 OAuth 사용을 고려하는 이유가 궁금하다면 Wikipedia를 시작하는 것이 좋습니다. 이 문서에서는 애플리케이션에서 OAuth를 사용하거나 OAuth를 구현하는 소프트웨어를 빌드하는 경우 영향을 줄 수 있는 제안된 OAuth 변경 사항을 다룹니다.
Why OAuth 2.1?
왜 OAuth 2.1인가?
It’s been a long time since OAuth 2.0 was released, so a consolidation point release will help make implementation simpler. As outlined in a blog post by Aaron Parecki, one of the authors of the OAuth 2.1 draft specification:
OAuth 2.0이 출시된 지 오랜 시간이 지났기 때문에 통합 포인트 출시는 구현을 더 간단하게 만드는 데 도움이 될 것입니다. OAuth 2.1 초안 사양 작성자 중 한 명인 Aaron Parecki의 블로그 게시물에 요약된 대로:
My main goal with OAuth 2.1 is to capture the current best practices in OAuth 2.0 as well as its well-established extensions under a single name. That also means specifically that this effort will not define any new behavior itself, it is just to capture behavior defined in other specs. It also won’t include anything considered experimental or still in progress.
OAuth 2.1의 주요 목표는 OAuth 2.0의 현재 모범 사례와 잘 확립된 확장 기능을 단일 이름으로 캡처하는 것입니다. 이는 또한 특히 이 노력이 새로운 동작 자체를 정의하지 않고 다른 사양에 정의된 동작을 캡처한다는 것을 의미합니다. 또한 실험적이거나 아직 진행 중인 것으로 간주되는 항목도 포함되지 않습니다.
OAuth 2.1 is not a scrape and rebuild of OAuth 2.0. Instead, OAuth 2.1 captures and consolidates changes and tweaks made to OAuth 2.0 over the past eight years. There’s a particular focus on better default security. It establishes best practices and will serve as a reference document going forward.
OAuth 2.1은 OAuth 2.0의 스크랩 및 재구축이 아닙니다. 대신 OAuth 2.1은 지난 8년 동안 OAuth 2.0에 적용된 변경 사항과 조정을 캡처하고 통합합니다. 더 나은 기본 보안에 특히 중점을 둡니다. 모범 사례를 수립하고 앞으로 참조 문서 역할을 할 것입니다.
Here’s a suggested description pulled from the ongoing mailing list discussion:
다음은 진행중인 메일링 리스트 토론에서 가져온 설명입니다.
By design, [OAuth 2.1] does not introduce any new features to what already exists in the OAuth 2.0 specifications being replaced.
설계상 [OAuth 2.1]은 대체되는 OAuth 2.0 사양에 이미 존재하는 기능에 새로운 기능을 도입하지 않습니다.
Many of the details are drawn from the OAuth 2.0 Security Best Current Practices document. In the name of security best practices, some of the more problematic grants will be removed.
많은 세부 정보는 OAuth 2.0 보안 모범 사례 문서에서 가져왔습니다. 보안 모범 사례의 이름으로 더 문제가 되는 일부 권한 부여가 제거됩니다.
At the end of the day, the goal of OAuth 2.1 is to have a single document explaining how to best implement and use OAuth, as both a client and an authorization server. No longer will developers be required to hunt across multiple RFCs and standards documents to understand how a particular behavior should be implemented or used.
결국 OAuth 2.1의 목표는 클라이언트와 인증 서버 모두로서 OAuth를 가장 잘 구현하고 사용하는 방법을 설명하는 단일 문서를 갖는 것입니다. 더 이상 개발자는 특정 동작을 구현하거나 사용해야 하는 방법을 이해하기 위해 여러 RFC 및 표준 문서를 검색할 필요가 없습니다.
How will OAuth 2.1 affect you?
OAuth 2.1은 당신에게 어떤 영향을 미치나요?
If you use OAuth in your application, don’t panic.
애플리케이션에서 OAuth를 사용하는 경우 당황하지 마십시오.
As mentioned above, the discussion process around this specification is ongoing. A draft was posted to the IETF mailing list in mid July and was adopted by the OAuth working group in July 2020. As of the time of writing, the draft is being reviewed and fine tuned.
위에서 언급한 바와 같이 이 사양에 대한 논의 과정이 진행 중입니다. 7월 중순에 IETF 메일링 리스트에 초안이 게시되었으며 2020년 7월에 OAuth 작업 그룹에서 채택되었습니다. 작성 시점에서 초안은 검토되고 미세 조정됩니다.
You may ask, when will it be available? The short answer is “no one knows”.
언제 사용할 수 있습니까? 짧은 대답은 "아무도 모른다"입니다.
The long answer is “truly, no one knows. It does seem like we’re getting along in the process, though.”
긴 대답은 "진실로 아무도 모릅니다. 그래도 우리는 그 과정을 함께 하고 있는 것 같습니다.”
Even after OAuth 2.1 is released, it will likely be some time before it is widely implemented. Omitted grants may be supported with, with nags or warnings, forever. The exact changes to the specification are still being discussed and the publishing of an RFC is further in the future. Finally, when OAuth 2.1 is released, you can continue to use an OAuth 2.0 server if that meets your needs.
OAuth 2.1이 출시된 후에도 널리 구현되기까지는 시간이 걸릴 것입니다. 생략된 보조금은 잔소리나 경고와 함께 영원히 지원될 수 있습니다. 사양에 대한 정확한 변경 사항은 아직 논의 중이며 RFC의 게시는 앞으로 더 진행됩니다. 마지막으로 OAuth 2.1이 출시되면 필요에 따라 OAuth 2.0 서버를 계속 사용할 수 있습니다.
That said, when OAuth 2.1 is released the largest impact on anyone using OAuth for authentication or authorization in their applications will be adapting to the removal of two OAuth 2.0 specified grants: the Implicit grant and the Resource Owner Password Credentials grant.
즉, OAuth 2.1이 출시되면 애플리케이션에서 인증 또는 권한 부여를 위해 OAuth를 사용하는 사람에게 가장 큰 영향을 미치는 것은 두 가지 OAuth 2.0 지정 권한, 즉 암시적 권한 부여 및 리소스 소유자 암호 자격 증명 권한 부여의 제거에 적응하는 것입니다.
What is changing from OAuth 2.0 to OAuth 2.1?
OAuth 2.0에서 OAuth 2.1로 변경되는 사항은 무엇입니까?
The draft RFC has a section outlining the major changes between OAuth 2.0 and OAuth 2.1. There may be changes not captured in that section but the authors’ goals are to document all formal changes there. There are six such changes:
RFC 초안에는 OAuth 2.0과 OAuth 2.1 간의 주요 변경 사항을 설명하는 섹션이 있습니다. 해당 섹션에 캡처되지 않은 변경 사항이 있을 수 있지만 작성자의 목표는 모든 공식 변경 사항을 문서화하는 것입니다. 다음과 같은 6가지 변경 사항이 있습니다.
The authorization code grant is extended with the functionality from PKCE (RFC7636) such that the default method of using the authorization code grant according to this specification requires the addition of the PKCE parameters
인증 코드 부여는 PKCE(RFC7636)의 기능으로 확장되어 이 사양에 따라 인증 코드 부여를 사용하는 기본 방법에는 PKCE 매개변수를 추가해야 합니다.
Redirect URIs must be compared using exact string matching as per Section 4.1.3 of OAuth 2.0 Security Best Current Practices
리디렉션 URI는 OAuth 2.0 보안 모범 사례의 섹션 4.1.3에 따라 정확한 문자열 일치를 사용하여 비교해야 합니다.
The Implicit grant ("response_type=token") is omitted from this specification as per Section 2.1.2 of OAuth 2.0 Security Best Current Practices
암시적 부여("response_type=token")는 OAuth 2.0 보안 모범 사례의 섹션 2.1.2에 따라 이 사양에서 생략됩니다.
The Resource Owner Password Credentials grant is omitted from this specification as per Section 2.4 of OAuth 2.0 Security Best Current Practices
리소스 소유자 비밀번호 자격 증명 부여는 OAuth 2.0 보안 모범 사례의 섹션 2.4에 따라 이 사양에서 생략되었습니다.
Bearer token usage omits the use of bearer tokens in the query string of URIs as per Section 4.3.2 of OAuth 2.0 Security Best Current Practices
무기명 토큰 사용은 OAuth 2.0 보안 모범 사례의 섹션 4.3.2에 따라 URI의 쿼리 문자열에서 무기명 토큰 사용을 생략합니다.
Refresh tokens must either be sender-constrained or one-time use as per Section 4.12.2 of OAuth 2.0 Security Best Current Practices
Refresh token은 OAuth 2.0 보안 모범 사례의 섹션 4.12.2에 따라 발신자 제한 또는 일회성 사용이어야 합니다.
Whew, that’s a lot. Let’s examine each of these in turn. But before we do, let’s define a few terms used in the rest of this article.
휴, 많군요. 이들 각각을 차례로 살펴보겠습니다. 하지만 그 전에 이 기사의 나머지 부분에서 사용되는 몇 가지 용어를 정의해 보겠습니다.
A client is a piece of code that the user is interacting with; browsers, native apps or single-page applications are all clients.
An OAuth server implements OAuth specifications. It has or can obtain information about which resources are available to clients. In the RFCs this application is called an Authorization Server. This is also known as an Identity Provider. Most users call it “the place I sign in”.
An application server doesn’t have any authentication functionality but instead delegates login requests to an OAuth server. It has an id which allows the OAuth server to identify it.
클라이언트는 사용자가 상호 작용하는 코드 조각입니다. 브라우저, 기본 앱 또는 단일 페이지 애플리케이션은 모두 클라이언트입니다.
OAuth 서버는 OAuth 사양을 구현합니다. 클라이언트가 사용할 수 있는 리소스에 대한 정보를 가지고 있거나 얻을 수 있습니다. RFC에서 이 애플리케이션을 Authorization Server라고 합니다. 이를 ID 공급자라고도 합니다. 대부분의 사용자는 이를 "내가 로그인하는 장소"라고 부릅니다.
애플리케이션 서버에는 인증 기능이 없지만 대신 OAuth 서버에 로그인 요청을 위임합니다. OAuth 서버가 식별할 수 있도록 하는 ID가 있습니다.
OAuth 2.1 change: The Authorization Code grant requires PKCE
OAuth 2.1 변경: 인증 코드 부여에는 PKCE가 필요합니다.
The authorization code grant is extended with the functionality from PKCE (RFC7636) such that the default method of using the authorization code grant according to this specification requires the addition of the PKCE parameters
인증 코드 부여는 PKCE(RFC7636)의 기능으로 확장되어 이 사양에 따라 인증 코드 부여를 사용하는 기본 방법에는 PKCE 매개변수를 추가해야 합니다.
Wow, that’s a lot. Let’s break that down. The Authorization Code grant is one of the most commonly used OAuth grants and is the most secure. If you’re into flow charts, here’s a post explaining the Authorization Code grant using a chart and walking through the grant step by step.
와, 정말 많네요. 분해해 보겠습니다. 인증 코드 부여는 가장 일반적으로 사용되는 OAuth 부여 중 하나이며 가장 안전합니다. 순서도에 관심이 있다면 차트를 사용하여 인증 코드 부여를 설명하고 부여를 단계별로 안내하는 게시물이 있습니다.
The Proof Key for Code Exchange (PKCE) RFC was published in 2015 and extends the Authorization Code grant to protect from an attack if part of the authorization flow happens over a non TLS connection. For example, this occurs if there’s communication between components of a native application.
PKCE(Proof Key for Code Exchange) RFC는 2015년에 게시되었으며 인증 흐름의 일부가 비 TLS 연결을 통해 발생하는 경우 공격으로부터 보호하기 위해 인증 코드 부여를 확장합니다. 예를 들어 네이티브 애플리케이션의 구성 요소 간에 통신이 있는 경우에 발생합니다.
This attack could also happen if TLS has a vulnerability or if a user’s router firmware has been compromised and is spoofing DNS or downgrading TLS to HTTP. PKCE requires an additional one-time code to be generated and sent to the OAuth server. This code validates the request has not been intercepted or modified.
이 공격은 TLS에 취약성이 있거나 사용자의 라우터 펌웨어가 손상되어 DNS를 스푸핑하거나 TLS를 HTTP로 다운그레이드하는 경우에도 발생할 수 있습니다. PKCE를 사용하려면 추가 일회성 코드를 생성하여 OAuth 서버로 보내야 합니다. 이 코드는 요청이 가로채거나 수정되지 않았는지 확인합니다.
The OAuth 2.1 draft specification requires the PKCE challenge be used with every Authorization Code grant, protecting against the authorization code being hijacked by an attacker and being used to gain a token.
OAuth 2.1 초안 사양에서는 모든 인증 코드 부여와 함께 PKCE 챌린지를 사용해야 하며, 인증 코드가 공격자에 의해 하이재킹되고 토큰을 얻는 데 사용되는 것을 방지합니다.
OAuth 2.1 change: Redirect URIs must be compared using exact string matching Redirect URIs must be compared using exact string matching as per Section 4.1.3 of OAuth 2.0 Security Best Current Practices
OAuth 2.1 변경: 정확한 문자열 일치를 사용하여 리디렉션 URI를 비교해야 합니다. 리디렉션 URI는 OAuth 2.0 보안 모범 사례의 섹션 4.1.3에 따라 정확한 문자열 일치를 사용하여 비교해야 합니다.
Some OAuth grants, notably the Authorization Code grant, are configured with one or more redirect URIs. One of these is then requested by the client when the grant starts. After the grant succeeds, the OAuth server sends the client to the requested redirect URI.
일부 OAuth 부여, 특히 인증 코드 부여는 하나 이상의 리디렉션 URI로 구성됩니다. 그 중 하나는 권한 부여가 시작될 때 클라이언트가 요청합니다. 승인이 성공하면 OAuth 서버가 클라이언트를 요청된 리디렉션 URI로 보냅니다.
Now, it would be convenient to support wildcards in this redirect URI list. At FusionAuth, we hear this request from folks who want to simplify their development or CI environments. Every time a new server is spun up, the redirect URI configuration needs to be updated to include the new URI.
이제 이 리디렉션 URI 목록에서 와일드카드를 지원하는 것이 편리할 것입니다. FusionAuth에서는 개발 또는 CI 환경을 단순화하려는 사람들로부터 이 요청을 듣습니다. 새 서버가 가동될 때마다 새 URI를 포함하도록 리디렉션 URI 구성을 업데이트해야 합니다.
For example, if a CI system builds an application for every feature branch, it might have the hostname dans-sample-application-1551.herokuapp.com, assuming the feature branch contains a fix for issue #1551. If I wanted to login using the Authorization Code grant, I’d have to update the redirect URI settings for my OAuth server to include that redirect URI: https://dans-sample-application-1551.herokuapp.com/oauth-callback.
예를 들어 CI 시스템이 모든 기능 분기에 대한 응용 프로그램을 빌드하는 경우 기능 분기에 문제 #1551에 대한 수정 사항이 포함되어 있다고 가정하면 호스트 이름이 dans-sample-application-1551.herokuapp.com일 수 있습니다. 인증 코드 부여를 사용하여 로그인하려면 리디렉션 URI를 포함하도록 OAuth 서버의 리디렉션 URI 설정을 업데이트해야 합니다. https://dans-sample-application-1551.herokuapp.com/oauth-callback .
When the next feature branch build happens, say for bug #1552, I’d have to add https://dans-sample-application-1552.herokuapp.com/oauth-callback and so on. Obviously, it’d be easier to set the redirect URI to a wildcard value such as https://dans-sample-application-*.herokuapp.com/oauth-callback. If this was the case, any URL matching that pattern would be acceptable to the OAuth server.
다음 기능 분기 빌드가 발생하면 버그 #1552에 대해 https://dans-sample-application-1552.herokuapp.com/oauth-callback 등을 추가해야 합니다. 분명히 리디렉션 URI를 https://dans-sample-application-*.herokuapp.com/oauth-callback과 같은 와일드카드 값으로 설정하는 것이 더 쉽습니다. 이 경우 해당 패턴과 일치하는 모든 URL이 OAuth 서버에서 허용됩니다.
An additional use case for a wild card redirect URI occurs when the final destination page needs dynamic parameters, like trackingparam=123&specialoffer=abc. These are usually appended to the redirect URI before the OAuth process begins. However, without wild cards, a URL with dynamic parameters won’t match any of the configured redirect URIs, so the redirect fails.
와일드 카드 리디렉션 URI의 추가 사용 사례는 최종 대상 페이지에 trackingparam=123&specialoffer=abc와 같은 동적 매개변수가 필요할 때 발생합니다. 일반적으로 OAuth 프로세스가 시작되기 전에 리디렉션 URI에 추가됩니다. 그러나 와일드 카드가 없으면 동적 매개변수가 있는 URL이 구성된 리디렉션 URI와 일치하지 않으므로 리디렉션이 실패합니다.
However, allowing wildcard matching for the redirect URI is a security risk. If the redirect URI matching is flexible, an attacker could send a user to an open redirect server controlled by them, and then on to a malicious destination. OWASP also discusses the perils of such open redirect servers. While this attack requires compromising the request in some fashion, using exact matching for redirect URIs eliminates this risk because the redirect URI is always a known value.
그러나 리디렉션 URI에 와일드카드 일치를 허용하면 보안 위험이 있습니다. 리디렉션 URI 일치가 유연한 경우 공격자는 사용자를 자신이 제어하는 개방형 리디렉션 서버로 보낸 다음 악의적인 대상으로 보낼 수 있습니다. OWASP는 또한 이러한 개방형 리디렉션 서버의 위험성에 대해 논의합니다. 이 공격은 어떤 방식으로든 요청을 손상시켜야 하지만 리디렉션 URI에 대해 정확한 일치를 사용하면 리디렉션 URI가 항상 알려진 값이기 때문에 이러한 위험이 제거됩니다.
OAuth 2.1 change: The Implicit grant is removed
OAuth 2.1 변경: 암시적 권한이 제거됨
The Implicit grant (“response_type=token”) is omitted from this specification as per Section 2.1.2 of OAuth 2.0 Security Best Current Practices
암시적 부여("response_type=token")는 OAuth 2.0 보안 모범 사례의 섹션 2.1.2에 따라 이 사양에서 생략됩니다.
The Implicit grant is inherently insecure when used in a single-page application (SPA). If you use this grant, your access token is exposed to any JavaScript running in the browser alongside your SPA. If you aren’t careful, you’ll get an access token that is in the URL fragment, stored in localstorage, or put in a non HttpOnly cookie. In all cases, an attacker gaining an access token is allowed to access resources as if they were the original user. This is not a good situation.
암시적 부여는 SPA(단일 페이지 응용 프로그램)에서 사용될 때 본질적으로 안전하지 않습니다. 이 권한을 사용하면 액세스 토큰이 SPA와 함께 브라우저에서 실행되는 모든 JavaScript에 노출됩니다. 조심하지 않으면 URL 조각에 있거나 localstorage에 저장되거나 HttpOnly가 아닌 쿠키에 저장되는 액세스 토큰을 얻게 됩니다. 모든 경우에 액세스 토큰을 획득한 공격자는 원래 사용자인 것처럼 리소스에 액세스할 수 있습니다. 이것은 좋은 상황이 아닙니다.
Access tokens are not necessarily one-time use, and can live from minutes to days depending on how the OAuth server is configured. If they are stolen, the resources they protect are no longer secure. You may think “well, I don’t have any malicious JavaScript on my site.” Are you sure? Have you audited all your code, and its dependencies, and their dependencies, and their dependencies? Do you audit your code automatically? Extensive dependency trees can lead to unforeseen security issues: someone took over an open source node library and added malicious code that was downloaded millions of times.
액세스 토큰은 반드시 한 번만 사용할 필요는 없으며 OAuth 서버 구성 방식에 따라 몇 분에서 며칠까지 사용할 수 있습니다. 도난당하면 보호하는 리소스가 더 이상 안전하지 않습니다. "글쎄, 내 사이트에 악성 JavaScript가 없다"고 생각할 수도 있습니다. 확실해? 모든 코드, 해당 종속성, 종속성 및 종속성을 감사했습니까? 코드를 자동으로 감사합니까? 광범위한 종속성 트리는 예상치 못한 보안 문제로 이어질 수 있습니다. 누군가 오픈 소스 노드 라이브러리를 인수하고 수백만 번 다운로드되는 악성 코드를 추가했습니다.
Here’s an article about the least insecure way to use the Implicit grant for an SPA. In this situation, the access token is provided to the SPA as an HttpOnly cookie. In the end it basically recreates the Authorization Code grant, illustrating how the Implicit grant simply can’t be made secure.
다음은 SPA에 대한 암시적 승인을 사용하는 가장 안전하지 않은 방법에 대한 기사입니다. 이 경우 액세스 토큰은 HttpOnly 쿠키로 SPA에 제공됩니다. 결국 기본적으로 인증 코드 부여를 다시 생성하여 암시적 부여가 단순히 보안이 될 수 없는 방법을 보여줍니다.
The OAuth 2.1 draft specification omits the Implicit grant. This means that any software implementing OAuth 2.1 won’t have to implement this grant. If you use this grant in your application, you’ll have to replace it with a different one if you want to be compliant with OAuth 2.1.
OAuth 2.1 초안 사양은 암시적 부여를 생략합니다.
즉, OAuth 2.1을 구현하는 소프트웨어는 이 권한을 구현할 필요가 없습니다. 애플리케이션에서 이 권한을 사용하는 경우 OAuth 2.1을 준수하려면 다른 권한으로 대체해야 합니다.
OAuth 2.1 change: The Resource Owner Password Credentials grant is removed
OAuth 2.1 변경: 리소스 소유자 비밀번호 자격 증명 부여가 제거되었습니다.
The Resource Owner Password Credentials grant is omitted from this specification as per Section 2.4 of OAuth 2.0 Security Best Current Practices
리소스 소유자 비밀번호 자격 증명 부여는 OAuth 2.0 보안 모범 사례의 섹션 2.4에 따라 이 사양에서 생략되었습니다.
This grant was added to the OAuth 2.0 specification with an eye toward making migration to OAuth compliant servers easier. In this grant, the application server receives the username and password (or other credentials) and passes it on to the OAuth server. Here’s an article breaking down each step of the Resource Owner Password Credentials grant.
이 권한은 OAuth 호환 서버로 더 쉽게 마이그레이션할 수 있도록 OAuth 2.0 사양에 추가되었습니다. 이 권한 부여에서 애플리케이션 서버는 사용자 이름과 비밀번호(또는 기타 자격 증명)를 수신하고 이를 OAuth 서버에 전달합니다. 다음은 리소스 소유자 암호 자격 증명 부여의 각 단계를 분석한 문서입니다.
This grant is often used for native mobile applications. While this grant made it easier to migrate to OAuth with minimal application changes, it doesn’t follow the typical delegation pattern. After all, the application server has full access to the credentials of the user, exactly what OAuth is designed to avoid. No longer can you leave the work of securing users’ credentials and data to the OAuth server. With this grant, you must ensure that your application backend is just as secure.
이 권한부여는 종종 네이티브 모바일 애플리케이션에 사용됩니다. 이 권한을 통해 애플리케이션 변경을 최소화하면서 OAuth로 쉽게 마이그레이션할 수 있었지만 일반적인 위임 패턴을 따르지는 않습니다. 결국 애플리케이션 서버는 사용자의 자격 증명에 대한 전체 액세스 권한을 가지며 정확히 OAuth가 방지하도록 설계된 것입니다. 더 이상 사용자의 자격 증명과 데이터를 보호하는 작업을 OAuth 서버에 맡길 수 없습니다. 이 권한을 통해 애플리케이션 백엔드도 마찬가지로 안전한지 확인해야 합니다.
If you have a mobile application using this grant, you can either update the client to use an Authorization Code grant using PKCE or keep using your OAuth 2.0 compliant system.
이 권한 부여를 사용하는 모바일 애플리케이션이 있는 경우 PKCE를 사용하는 인증 코드 권한 부여를 사용하도록 클라이언트를 업데이트하거나 OAuth 2.0 호환 시스템을 계속 사용할 수 있습니다.
OAuth 2.1 change: No bearer tokens in the query string
Bearer token usage omits the use of bearer tokens in the query string of URIs as per Section 4.3.2 of OAuth 2.0 Security Best Current Practices
OAuth 2.1 변경: 쿼리 문자열에 전달자 토큰이 없습니다.
무기명 토큰 사용은 OAuth 2.0 보안 모범 사례의 섹션 4.3.2에 따라 URI의 쿼리 문자열에서 무기명 토큰 사용을 생략합니다.
Bearer tokens, also known as access tokens, allow access to protected resources and therefore must be secured. They are called bearer tokens because merely possessing them gives you access. They’re like a set of house keys.
액세스 토큰이라고도 하는 Bearer Token은 보호된 리소스에 대한 액세스를 허용하므로 보안을 유지해야 합니다. 보유하는 것만으로도 액세스가 가능하기 때문에 무기명 토큰이라고 합니다. 그들은 집 열쇠 세트와 같습니다.
These days, most tokens are JWTs. Clients store them securely and then use them to make API calls to the application server. The application server then uses the token to ensure the client calling the API has appropriate permissions. When first defined in RFC 6750, tokens were allowed in headers, POST bodies or query strings. The OAuth 2.1 draft prohibits sending a bearer token in a query string.
요즘 대부분의 토큰은 JWT입니다. 클라이언트는 이를 안전하게 저장한 다음 이를 사용하여 애플리케이션 서버에 대한 API 호출을 수행합니다. 그런 다음 애플리케이션 서버는 토큰을 사용하여 API를 호출하는 클라이언트에 적절한 권한이 있는지 확인합니다. RFC 6750에서 처음 정의되었을 때 토큰은 헤더, POST 본문 또는 쿼리 문자열에서 허용되었습니다. OAuth 2.1 초안은 쿼리 문자열에 Bearer Token을 보내는 것을 금지합니다.
A query string and, more generally, any string in a URL, is never private. JavaScript executing on a page can access it. A URL or components thereof may be recorded in server log files, caches, or browser history. In general, if you want to pass information privately over the internet, don’t use anything in a URL. Instead, use TLS and put the sensitive information in a POST body or HTTP header.
쿼리 문자열 및 URL의 모든 문자열은 비공개가 아닙니다. 페이지에서 실행되는 JavaScript는 페이지에 액세스할 수 있습니다. URL 또는 그 구성 요소는 서버 로그 파일, 캐시 또는 브라우저 기록에 기록될 수 있습니다. 일반적으로 인터넷을 통해 비공개로 정보를 전달하려는 경우 URL에 아무 것도 사용하지 마십시오. 대신 TLS를 사용하고 민감한 정보를 POST 본문이나 HTTP 헤더에 넣습니다
OAuth 2.1 change: Limiting refresh tokens
OAuth 2.1 변경: Refresh Token 제한
Refresh tokens must either be sender-constrained or one-time use as per Section 4.12.2 of OAuth 2.0 Security Best Current Practices
Refresh Token은 OAuth 2.0 보안 모범 사례의 섹션 4.12.2에 따라 발신자 제한 또는 일회성 사용이어야 합니다.
Refresh tokens allow a client to retrieve new access tokens without reauthentication by the resource owner. If you need access to a resource for longer than an access token lives, or if you need infrequent access, refresh tokens can help. One example of where a refresh token might be used is when a user is logged into their email for weeks or months. Every time an access token expires, the client can present a refresh token and get a new access token.
Refresh Token을 사용하면 클라이언트가 리소스 소유자의 재인증 없이 새 액세스 토큰을 검색할 수 있습니다. 액세스 토큰의 수명보다 더 오래 리소스에 액세스해야 하거나 자주 액세스해야 하는 경우 토큰 새로 고침이 도움이 될 수 있습니다. 새로 고침 토큰이 사용될 수 있는 한 가지 예는 사용자가 몇 주 또는 몇 달 동안 이메일에 로그인한 경우입니다. 액세스 토큰이 만료될 때마다 클라이언트는 새로 고침 토큰을 제시하고 새 액세스 토큰을 얻을 수 있습니다.
Refresh tokens are longer lived than access tokens and have a higher level of privilege, since they can be used to create entirely new access tokens. Therefore you should take more care when securing a refresh token. Never share your refresh tokens between different devices.
Refresh Token은 액세스 토큰보다 수명이 길고 완전히 새로운 액세스 토큰을 만드는 데 사용할 수 있기 때문에 더 높은 수준의 권한을 갖습니다. 따라서 새로 고침 토큰을 확보할 때 더 주의해야 합니다. 다른 장치 간에 새로 고침 토큰을 공유하지 마십시오.
If they are acquired by an attacker, they can create access tokens at will. Obviously at that point, the resource which the access tokens protect will no longer be secured. As an example of how to secure refresh tokens, here’s a post using the Authorization Code grant which stores refresh tokens using HttpOnly cookies with a constrained cookie domain, and you can learn more about FusionAuth’s access and refresh tokens here.
공격자에게 획득한 경우 마음대로 액세스 토큰을 생성할 수 있습니다. 분명히 그 시점에서 액세스 토큰이 보호하는 리소스는 더 이상 보호되지 않습니다. 새로 고침 토큰을 보호하는 방법의 예로 제한된 쿠키 도메인과 함께 HttpOnly 쿠키를 사용하여 새로 고침 토큰을 저장하는 인증 코드 부여를 사용하는 게시물이 있으며 여기에서 FusionAuth의 액세스 및 새로 고침 토큰에 대해 자세히 알아볼 수 있습니다.
The OAuth 2.1 draft provides two options for refresh tokens: they can be one-time use or tied to the sender with a cryptographic binding.
OAuth 2.1 초안은 새로 고침 토큰에 대해 두 가지 옵션을 제공합니다. 즉, 일회용이거나 암호화 바인딩을 사용하여 발신자와 연결될 수 있습니다.
With one time use refresh tokens, after a refresh token (call it refresh token A) is used to retrieve a new access token, it becomes invalid. The OAuth server may send a new refresh token (call it refresh token B) along with the requested access token. Once the newly delivered access token expires, the client can request another access token using refresh token B, and receive the new access token and refresh token C, and so on and so on. The change to one-time use refresh tokens may require changing client code to store the new refresh token on every refresh of the access token.
Refresh Token을 한 번 사용하면 Refresh Token(Refresh Token A라고 함)을 사용하여 새 Refresh Token을 검색한 후 무효화됩니다. OAuth 서버는 요청된 Access Token과 함께 새 Refresh Token(Refresh Token B라고 함)을 보낼 수 있습니다. 새로 전달된 Access Token이 만료되면 클라이언트는 Refresh Token B를 사용하여 다른 Access Token을 요청할 수 있으며 새 Access Token과Refresh Token C를 받는 식으로 계속됩니다. 일회용 새로 고침 토큰으로 변경하려면 액세스 토큰을 새로 고칠 때마다 새 새로 고침 토큰을 저장하도록 클라이언트 코드를 변경해야 할 수 있습니다.
The other option is to ensure the OAuth server cryptographically binds the refresh token to the client. The options mentioned in the “OAuth 2.0 Security Best Current Practices” document include OAuth token binding, Mutual TLS authentication RFC 8705 and DPoP, among others. All of these binding methods ensure the request came from the client to which the refresh token was issued.
다른 옵션은 OAuth 서버가 새로 고침 토큰을 클라이언트에 암호화 방식으로 바인딩하도록 하는 것입니다. "OAuth 2.0 Security Best Current Practices" 문서에 언급된 옵션에는 OAuth 토큰 바인딩, 상호 TLS 인증 RFC 8705 및 DPoP 등이 있습니다. 이러한 모든 바인딩 방법은 새로 고침 토큰이 발급된 클라이언트에서 요청이 왔는지 확인합니다.
To sum up, the OAuth 2.1 draft requires an OAuth server protect refresh tokens by requiring them to either be one-time use or by using cryptographic proof of client association. Both options protect these powerful tokens from being used by an attacker.
요약하자면, OAuth 2.1 초안은 OAuth 서버가 일회성 사용을 요구하거나 클라이언트 연결의 암호화 증명을 사용하여 Refresh Token을 보호하도록 요구합니다. 두 옵션 모두 공격자가 이러한 강력한 토큰을 사용하지 못하도록 보호합니다.
What’s unchanged?
These are the major changes in the proposed OAuth 2.1 draft. The OAuth 2.1 spec is built on the foundation of the OAuth 2.0 RFCs and inherits all behavior not explicitly omitted or changed. For example, the Client Credentials grant, often used for server to server communication, will still be available.
다음은 제안된 OAuth 2.1 초안의 주요 변경 사항입니다. OAuth 2.1 사양은 OAuth 2.0 RFC를 기반으로 구축되었으며 명시적으로 생략되거나 변경되지 않은 모든 동작을 상속합니다. 예를 들어, 서버 간 통신에 자주 사용되는 클라이언트 자격 증명 부여는 계속 사용할 수 있습니다.
Can you use OAuth 2.1 right now?
지금 OAuth 2.1을 사용할 수 있습니까?
As of now, there’s nothing stamped “OAuth 2.1”. And the draft spec isn’t finalized. But if you follow best practices around security, you can reap the benefits of this consolidated draft, as well as prepare your applications for its release.
현재로서는 "OAuth 2.1"이라고 표시된 것이 없습니다. 그리고 초안 사양이 확정되지 않았습니다. 그러나 보안에 대한 모범 사례를 따르면 이 통합 초안의 이점을 얻을 수 있을 뿐만 아니라 릴리스를 위해 애플리케이션을 준비할 수 있습니다.
When writing a client application, avoid the Implicit grant and the Resource Owner Password Credentials grant.
클라이언트 응용 프로그램을 작성할 때 암시적 부여 및 리소스 소유자 암호 자격 증명 부여를 피하십시오.
Make sure your OAuth server is doing to following:
OAuth 서버가 다음을 수행하는지 확인하십시오.
Using PKCE whenever you use the Authorization Code grant.
Make sure that your redirect URIs are compared using exact string matches, not wildcard or substring matching.
Make sure bearer tokens are never present in the query string.
Limit your refresh tokens, either by making them one time use or having them be sender constrained.
What’s next for OAuth
Prediction is very difficult, especially if it’s about the future. - Niehls Bohr
인증 코드 부여를 사용할 때마다 PKCE를 사용합니다.
와일드카드 또는 하위 문자열 일치가 아닌 정확한 문자열 일치를 사용하여 리디렉션 URI를 비교해야 합니다.
전달자 토큰이 쿼리 문자열에 존재하지 않는지 확인하십시오.
Refresh Token을 한 번만 사용하거나 발신자를 제한하여 제한하십시오.
OAuth의 다음 단계
특히 미래에 관한 것이라면 예측은 매우 어렵습니다. - 닐스 보어
OAuth 2.1 is still being discussed on the IETF OAuth mailing list. If you are interested in following or influencing this RFC, review the discussion archives to get up to speed. You can also join the mailing list.
OAuth 2.1은 IETF OAuth 메일링 리스트에서 여전히 논의 중입니다. 이 RFC를 따르거나 영향을 미치는 데 관심이 있다면 토론 아카이브를 검토하여 최신 정보를 얻으십시오. 메일링 리스트에 가입할 수도 있습니다.
Looking beyond OAuth 2.1, which, as mentioned, aims to consolidate security best practices but leave most of the rest of OAuth 2.0 untouched, there’s also a “next gen” working group, reimagining a Grant Negotiation and Authorization Protocol from the ground up. This protocol aims to cover the same use cases as OAuth2, but explicitly rules out backward compatibility:
앞서 언급한 것처럼 보안 모범 사례를 통합하는 것을 목표로 하지만 OAuth 2.0의 나머지 부분은 그대로 둔 OAuth 2.1 외에도 보조금 협상 및 승인 프로토콜을 처음부터 다시 상상하는 "차세대" 작업 그룹도 있습니다. 이 프로토콜은 OAuth2와 동일한 사용 사례를 다루는 것을 목표로 하지만 이전 버전과의 호환성을 명시적으로 배제합니다.
“Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.”
"이 작업을 위한 아티팩트가 OAuth 2.0 또는 OpenID Connect와 역호환되도록 의도되거나 예상되지는 않지만, 그룹은 가능한 경우 OAuth 2.0 및 OpenID Connect에서 새 프로토콜로의 마이그레이션을 단순화하려고 시도할 것입니다."
The GNAP specification is further from release than the OAuth 2.1 specification.
GNAP 사양은 OAuth 2.1 사양보다 출시가 멀었습니다.
참조
