타사 API 를 통합한 모든 개발자는 같은 벽에 부딪혔습니다: 문서들은 "basic auth," 로 인증; 키와 비밀을 요청에 붙여넣으면 서버는 플랫으로 응답합니다 401 Unauthorized 그리고 왜 그런지에 대한 힌트는 없습니다. 10 번 중 9 번은 자격 증명이 약간 잘못 인코딩되었으며 오류에는 그 사실을 알려주는 것이 없습니다. 나는 WordPress 플러그인과 Laravel 백엔드를 통해 충분한 API 를 구축하고 소비하여 정확히 이것에 대해 당황스러운 시간을 낭비했기 때문에 a 를 넣었습니다 기본 인증 생성기 에 Toolz.dev 그것은 헤더를 매번 올바르게 만들고 확인해야 할 때 헤더를 다시 디코딩합니다. 이것은 헤더와 그 뒤에 있는 구성표에 대한 가이드입니다.
TL;DR: HTTP 기본 인증은 사용자 이름과 비밀번호를 다음과 같이 보냅니다
base64(username:password)에서Authorization헤더. 도구 기본 인증 생성기 사용자 이름과 암호를 정확한 헤더,즉시 실행 가능한 컬 명령,fetch 스니펫 및 URL userinfo 양식으로 바꾸면 기존 토큰을 다시 디코딩합니다. UTF-8 을 통해 인코딩하므로 비 ASCII 자격 증명이 살아남고 사용자 이름에 콜론이 포함되어 있을 때 경고하며 완전히 클라이언트 측으로 실행됩니다.
HTTP 기본 인증이란 무엇입니까?
HTTP 기본 인증은 웹이 정의하는 가장 간단한 자격 증명 체계입니다. 에 지정되어 있습니다 RFC 7617는 일반적인 HTTP 인증 프레임워크 위에 있습니다 RFC 7235. 아이디어는 최소: 당신이 누구인지 증명하기 위해,당신은 a 를 보냅니다 Authorization 값이 단어인 헤더입니다 Basic, 공백, 그리고 단일 콜론으로 연결된 사용자 이름과 비밀번호의 base64 인코딩입니다.
구체적으로 사용자 이름이 다음과 같은 경우 admin 그리고 당신의 비밀번호는 secret는, 클라이언트가 문자열을 형성합니다 admin:secret는, UTF-8 바이트로 그것을 부호화하고, base64-얻기 위하여 그 바이트를 부호화합니다 YWRtaW46c2VjcmV0, 그리고 보낸다:
Authorization: Basic YWRtaW46c2VjcmV0
그것이 전체 구성표입니다. 악수도 없고,nonce 도 없고,해싱도 없습니다. 그것의 단순함이 정확히 그것이 살아남은 이유입니다: 양쪽 끝에서 구현하는 것은 사소한 것이고,내부 도구,개인 레지스트리,웹훅, 그리고 셀 수 없이 많은 API 의 경우 여전히 기본값이고,큰 것은 인코딩이 완전히 되돌릴 수 있다는 것입니다. 이것은 어떻게 사용해야 하는지에 대한 모든 것을 형성합니다.
base64 인코딩은 암호화와 동일합니까?
아니요, 이것이 Basic auth에 대해 이해해야 할 가장 중요한 것입니다. Base64, 에서 정의됨 RFC 4648는, 수송 부호화입니다. 그것의 목적은 64 의 인쇄할 수 있는 문자의 안전한 세트를 사용하여 이진 또는 원본 자료를 대표하기 위한 것입니다 그래서 원본을 예상하는 체계를 통해서 보내지는 살아납니다. 암호가 아닙니다,아무 열쇠도 이용하지 않으며,반전하는 것은 1 개 단계를 볼 수 있는 누구 YWRtaW46c2VjcmV0 다시 디코딩할 수 있습니다 admin:secret 즉시, 이 tool's 디코드 모드가 하는 것입니다.
그 결과 Basic 인증은 그 자체로 기밀성이 0이 됩니다. 자격 증명은 단지 얇은 변장을 한 채 투명하게 효과적으로 전송됩니다. 이것이 바로 Basic auth의 협상 불가능한 규칙 중 하나가 HTTPS를 통해서만 이동해야 한다는 것입니다. TLS는 다음을 포함하여 전체 요청을 암호화합니다 Authorization 헤더이므로 base64 자격 증명은 전송 중에 보호됩니다. 일반 HTTP를 통해 기본 인증 을 보내면 네트워크 경로에 있는 모든 사람에게 암호를 게시했습니다.
base64 단계가 사람들이 자격 증명이 의미 있는 방식으로 뒤섞여 있다고 생각하도록 속이기 때문에 이 점을 해결합니다. 그렇지 않습니다. base64 토큰을 원시 비밀번호를 처리하는 것과 동일한 주의로 처리하십시오. 왜냐하면 그것들은 사소하게 상호 변환 가능하기 때문입니다. 그만큼 데이터 개인 정보 보호 온라인 도구 가이드는 이 도구가 서버가 아닌 브라우저에서 인코딩을 수행하는 이유를 다룹니다. 이는 라이브 자격 증명의 경우 핵심입니다.
Basic auth 헤더는 단계별로 어떻게 구축되나요?
구성은 네 개의 작은 단계이며, 그 중 약간 잘못된 것을 얻으면 조용히 실패하는 자격 증명이 생성됩니다:
- 콜론으로 가입. 문자열을 형성합니다
username:password. 콜론은 구분 기호입니다. - UTF-8 로 인코딩. UTF-8 을 사용하여 해당 문자열을 바이트로 바꿉니다. 이는 ASCII 가 아닌 모든 문자에 중요합니다.
- Base64-바이트를 인코딩합니다. 토큰을 생성하기 위해 표준 base64를 적용합니다.
- 접두사 with
Basic. 마지막 헤더 값은Basic토큰이 뒤따릅니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 발전기 네 가지를 모두 수행하고 완성된 헤더를 건네줍니다. 또한 터미널이나 코드베이스에 실제로 붙여넣는 양식도 생성합니다: 컬 명령은 다음을 사용합니다 -u 플래그, 명시적인 컬 명령입니다 -H 'Authorization: Basic ...' 헤더, 가져오기 스니펫, 자체 토큰 및 URL userinfo 양식 https://user:pass@host. 다른 작업은 다른 형태를 원하며,base64 를 손으로 다시 입력하는 것은 정확하게 실수가 들어오는 곳입니다.
왜 비밀번호보다 사용자 이름이 더 중요합니까?
계획에는 사람들을 끊임없이 넘어뜨리는 하나의 비대칭성이 있는데, 이는 1단계에서 바로 나옵니다. 자격 증명은 에 분할됩니다 첫번째 콜론. 즉,사용자 이름에 콜론을 포함할 수 없다는 뜻입니다. 서버가 사용자 이름의 첫 번째 콜론을 경계로 읽고 나머지 콜론을 암호 필드에 넘겨주기 때문입니다. 이와 대조적으로 암호에는 원하는 만큼의 콜론이 포함될 수 있습니다. 첫 번째 콜론 이후의 모든 것이 암호이기 때문입니다.
RFC 7617 은 이것을 직접적으로 기술한다: user-id 는 콜론을 포함해서는 안된다. 이것은 특히 사용자 이름이 그 자체로 API 키나 우연히 콜론을 포함하는 이메일 모양의 식별자와 같은 구조화된 것일 때,눈치채지 못한 채 위반하기 쉽다. 생성기는 정확히 이것을 주시하고 사용자 이름이 콜론을 포함할 때 경고하는데,그 이유는 결과 자격 증명이 잘못된 위치에 분할된 상태로 디코딩되어 원인에 대한 단서를 주지 않는 401 을 생성하기 때문이다.
명확하게 설명할 가치가 있기 때문에 여기에 테이블의 규칙이 있습니다.
| 필드 | 결장이 포함될 수 있나요? | 이유 |
|---|---|---|
| 사용자 이름 | 아니요 | 첫 번째 콜론은 구분 기호입니다 |
| 비밀번호 | 예 | 첫 번째 콜론 이후의 모든 것은 암호입니다 |
나는이 정확한 실패를 야생에서 디버깅했는데,서비스는 API "usernames"를 발행했으며 때때로 콜론을 포함하고 통합은 대부분의 고객에게 효과가 있었고 신비롭게도 몇 가지 실패했다. tool's 경고는 그날 오후를 저장했을 것입니다.
UTF-8 인코딩이 중요한 이유는 무엇입니까?
모든 ASCII 사용자 이름과 암호의 경우 인코딩 단계는 보이지 않습니다; 모든 문자는 1 바이트이고 base64 는 그 일을 합니다. 자격 증명에 악센트가 있는 문자, 비라틴어 스크립트 또는 이모티콘이 포함되는 순간 바이트 인코딩이 결정적이 됩니다. RFC 7617 은 클라이언트와 서버가 이러한 문자의 바이트에 동의하도록 UTF-8 을 정확하게 권장합니다.
한 문자를 1바이트로 가정하거나 레거시 동작이 있는 브라우저 API에 의존하는 순진한 인코더는 손상됩니다 café 또는 пароль 잘못된 바이트로,그리고 그것이 생성하는 base64 토큰은 호환 서버가 동일한 자격 증명에서 계산한 것과 일치하지 않습니다. 결과는 또 다른 침묵 401 입니다. 이 생성기는 손으로 UTF-8 을 통해 자격 증명을 인코딩하므로 암호와 같습니다 café:naïve RFC 7617 클라이언트가 보낼 바이트를 정확히 생성하고,디코드 측은 이를 충실하게 반전시킵니다. 만약 당신이 다른 팀원이 아닌 한 팀원에게 작동하는 자격 증명을 가지고 있다면,일관되지 않게 인코딩된 비 ASCII 문자가 주요 용의자입니다.
Basic auth 토큰을 어떻게 디코딩합니까?
인코딩은 되돌릴 수 있기 때문에 자격 증명을 확인하는 것은 자격 증명을 생성하는 것만큼 쉽습니다. 다음 부분을 취하십시오 Basic 을,base64-decode 하고,결과를 UTF-8 로 읽고,첫번째 콜론에서 split 합니다. The 발전기's 디코드 모드는 이것을 한다: 가득 차있는 풀 Authorization: Basic ... 라인, 베어 Basic ... 값 또는 토큰만 표시되며 해당 토큰에 포함된 사용자 이름과 비밀번호가 표시됩니다.
이것은 단지 호기심이 아니라 진정으로 유용합니다. 작업 자격 증명을 건네 받고 새로운 환경에서 재생산하도록 요청받을 때 디코딩은 인코딩하는 사용자 이름과 암호를 정확하게 알려주기 때문에 올바르게 설정할 수 있습니다. 통합이 실패하면 실제로 보내는 토큰을 디코딩하고 의도 한 것과 비교하는 것이 종종 길 잃은 공간,잘못된 필드 또는 잘못된 위치에있는 콜론을 발견하는 가장 빠른 방법입니다. 그리고 위의 기밀 유지 지점을 생생하게 상기시켜줍니다: 이렇게 쉽게 디코딩 할 수 있다면 일반 HTTP 를 통해 가로 채는 사람이라면 누구나 할 수 있습니다.
발전기가 다른 도구와 맞는 곳
Basic auth 는 동일한 클라이언트 측,업로드 없음 모델을 공유하는 사이트의 여러 자격 증명 및 요청 도구 중 하나입니다. 검사하는 토큰이 Basic auth 가 아닌 베어러 토큰인 경우,the JWT 디코더 JSON 웹 토큰에서 주장을 읽습니다. 인코딩이 아닌 해시가 필요한 경우 체크섬이나 비밀번호 다이제스트를 위해 해시 생성기 계산합니다. 단지 자격 증명이 아닌 임의의 base64 를 구체적으로 인코딩하거나 디코딩하고자 할 때, the base64 변환기 일반적인 경우를 처리합니다. 그리고 요청 자체를 디버깅하고 어떤 클라이언트가 보냈는지 알고 싶을 때,the 사용자 에이전트 파서 user-agent 헤더를 읽습니다.
이러한 요청 및 응답 유틸리티가 어떻게 함께 작동하는지에 대한 더 넓은 지도를 보려면, 웹 개발자 툴킷 roundup은 현실적인 디버깅 세션을 거칩니다 개발자 생산성 도구 가이드는 그들의 개인적인 세트를 조립하는 덮개. 기본적인 auth 는 고립에서 드물게 온다; 그것은 당신이 일을 만들려고 하는 요구에서 보통 1 개의 선이다.
실제 사례: API 통합 연결
제가 가장 많이 치는 작업에서 이것을 접지하겠습니다. 여러분은 문서들이 사용자 이름과 빈 암호로 API 키를 사용하여 Basic auth 로 인증하라고 말하는 타사 서비스를 통합하고 있거나 키와 비밀 쌍을 가지고 있습니다. 문서들은 당신에게 자격 증명을 주지만 헤더는 주지 않으며,첫 번째 요청은 실패합니다.
신뢰할 수 있는 경로는 헤더를 명시적으로 빌드하고 응용 프로그램 코드 줄을 작성하기 전에 컬로 테스트하는 것입니다. 키와 비밀을 에 붙여넣습니다 발전기, 복사하세요 curl -H 양식,그리고 알려진 엔드포인트에 대해 실행. curl 성공하고 코드가 그렇지 않은 경우 문제는 cord's 요청 구성에 있는 것이지 자격 증명이 아니며 검색 공간을 반으로 잘라낸 것입니다. curl 도 실패하면 자격 증명 자체가 잘못되고 토큰을 디코딩하면 정확히 어느 필드가 꺼져 있는지 확인됩니다.
워드 프레스 플러그인에서 나는 종종 PHP에서 외부 API를 호출해야하고, 올바른 헤더 값은 내가에 공급되는 것입니다 wp_remote_get 통해 Authorization 헤더 인수. Laravel 에서 그것은에 간다 withHeaders HTTP 클라이언트를 호출하거나,framework's 를 사용합니다 withBasicAuth 나를 위해 동일한 헤더를 빌드하는 Helper. 어느 쪽이든,생성기에서 알려진 좋은 헤더 값을 갖는 것은 내가 이미 작동을 입증한 자격 증명에 대해 내 요청 코드를 디버깅한다는 것을 의미합니다. 두 가지를 동시에 디버깅하는 것이 아니라 빈 비밀번호 케이스는 생성기가 유지 비용을 얻는 곳입니다. 왜냐하면 그것을 잊어버리기 쉽기 때문입니다 key: 후행 콜론의 경우 다른 자격 증명이며 종종 올바른 자격 증명입니다 key 혼자.
마지막 규율은 보안입니다. 결과 헤더를 공유 문서,티켓 또는 채팅에 붙여 넣지 말고 HTTPS 이외의 다른 것을 통해 Basic auth 를 보내지 마십시오. 토큰은 암호입니다. 이 도구는 브라우저에서 인코딩하고 아무 것도 업로드하지 않기 때문에 자격 증명을 생성하는 것은 안전합니다; 이후에가는 곳은 당신에게 있습니다.
Basic auth 는 언제 사용해야 하고,언제 사용하지 말아야 하나요?
Basic auth 는 모든 작업에 적합한 도구가 아니며,어디에 적합한지 알면 문제가 발생하지 않습니다. 그 강점은 단순성입니다: 서버 간 호출,내부 도구,개인 패키지 레지스트리,CI 작업 및 두 끝이 이미 서로를 신뢰하고 모든 것이 HTTPS 를 통해 실행되는 웹훅의 경우 이길 수 없습니다. 협상할 것도 없고 새로 고칠 토큰도 없으며 모든 HTTP 클라이언트와 라이브러리가 즉시 지원합니다. 양쪽을 제어하고 연결이 암호화되면 Basic auth 는 30 년 동안 계속 작동해 온 완벽하게 합리적인 선택입니다.
그 약점은 그 상자 밖으로 나가는 순간 나타납니다. 모든 요청에 대해 자격 증명이 전송되기 때문에,유출된 단일 로그 라인이나 헤더를 기록하는 프록시가 영구적으로 노출되고,회전한다는 것은 모든 곳에서 한 번에 변경하는 것을 의미합니다. 범위에 대한 개념이 없으므로 기본 자격 증명은 전부 아니면 전무입니다: 읽기 전용 액세스를 허용하거나 한 시간 후에 만료할 수 없습니다. 그리고 모든 통화에서 실제 수명이 긴 비밀번호를 유선에 입력하는 반면,토큰 기반 체계는 대신 수명이 짧고 범위가 좁은 자격 증명을 배포할 수 있습니다.
사용자 대면 인증이나 범위, 만료 또는 취소가 필요한 모든 경우 베어러 토큰이 더 나은 모델입니다 JWT 디코더 는 이들을 검사하기 위한 동반 도구입니다. 유용한 경험 법칙: reach for Basic auth for machine-to-machine 호출을 위한 완전 제어,그리고 제 3 자,브라우저 세션 또는 권한 경계가 관련될 때 토큰에 대한 도달 범위 아래 표는 거래를 요약합니다.
| Basic auth를 사용하세요 | 토큰을 선호합니다 |
|---|---|
| 제어하는 서버 간 API 호출 | 사용자 대면 세션 |
| 내부 도구 및 개인 레지스트리 | 범위 지정 또는 읽기 전용 액세스 |
| HTTPS를 통한 CI 작업 및 웹훅 | 만료되어야 하는 자격 증명 |
자주 묻는 질문
HTTP 기본 인증이란 무엇입니까? HTTP 기본 인증은 클라이언트가 Authorization 헤더의 각 요청과 함께 사용자 이름과 암호를 보내는 체계입니다. 값은 Basic 이라는 단어 뒤에 username:password 의 base64 인코딩이 옵니다. RFC 7617 에 정의되어 있으며 서버가 자격 증명을 확인하는 가장 간단한 방법입니다.
Basic auth 헤더는 어떻게 구축되나요? 사용자 이름과 암호를 단일 콜론으로 결합하여 사용자 이름: 암호를 형성하고,해당 문자열을 UTF-8 바이트로 인코딩하고,바이트를 base64-인코딩하고,결과에 Basic 을 접두사로 붙입니다. 최종 헤더는 Authorization: Basic 다음에 해당 토큰이 옵니다.
Basic 인증은 안전한가요? HTTPS 를 통해서만 가능합니다. Base64 는 암호화가 아니라 인코딩이므로 헤더를 읽을 수 있는 사람은 누구나 즉시 암호를 해독할 수 있습니다. Basic auth 는 그 자체로는 기밀성을 제공하지 않으며 항상 TLS 연결을 통해 전송해야 안전합니다.
사용자 이름에 콜론이 포함될 수 있나요? 아니요. 첫 번째 콜론은 사용자 이름과 암호를 분리하므로 사용자 이름의 콜론은 경계로 잘못 읽혀지고 자격 증명을 잘못된 위치에 분할합니다. 암호에는 임의의 수의 콜론이 포함될 수 있습니다. 생성기는 사용자 이름에 콜론이 있는 경우 경고합니다.
Basic auth 토큰을 어떻게 디코딩합니까? Basic 다음에 base64 부분을 가져와서 base64-decode 하고 UTF-8 텍스트로 읽습니다. 결과는 사용자 이름: password, 첫 번째 콜론에 분할됩니다. tool's 디코드 모드에 Basic auth 헤더를 붙여넣으면 즉시 실행됩니다.
컬은 무엇 동등물입니까? curl -u 사용자 이름:password https://example.com curl 이 -u 값에서 당신을 위해 Authorization: Basic 헤더를 빌드하기 때문에 동일한 작업을 수행합니다. 도구는 해당 양식과 명시적인 -H 헤더 양식을 모두 보여 주므로 맞는 것을 복사 할 수 있습니다.
이 도구는 내 자격 증명을 아무 곳이나 보내나요? 아니요. 인코딩 및 디코딩은 전적으로 JavaScript 로 브라우저에서 실행됩니다. 사용자 이름과 암호는 어떤 서버에도 업로드되지 않으므로 실제 라이브 자격 증명으로 사용하는 것이 안전합니다.
자격 증명에 UTF-8 인코딩을 사용하는 이유는 무엇입니까? RFC 7617 은 ASCII 가 아닌 사용자 이름과 암호가 클라이언트와 서버 간에 일관되게 인코딩되도록 UTF-8 을 권장합니다. ASCII 를 가정하는 인코더는 악센트 문자 또는 비 라틴어 스크립트를 손상시켜 서버가 일치 할 수없는 토큰을 생성합니다.
