API에 요청을 보낼 때 클라이언트를 인증해야합니다. 클라이언트에는 API 토큰이 있으며 표준 Authorization헤더를 사용 하여 토큰을 서버로 보낼 생각이었습니다 .
일반적으로이 헤더가 사용됩니다 Basic및 Digest인증. 하지만이 헤더의 값을 사용자 정의하고 사용자 정의 인증 체계를 사용할 수 있는지 여부를 모르겠습니다. 예 :
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
이것을 추천 하시겠습니까? 아니면 토큰을 보내는 더 나은 방법이 있습니까?
답변:
Authorization:헤더 를 사용하는 사용자 지정 인증 스키마를 만들 수 있습니다 ( 예 : OAuth의 작동 방식).
일반적으로 서버 또는 프록시가 표준 헤더 의 값 을 이해하지 못하면 그대로두고 무시합니다. 종종 예기치 않은 결과를 생성 할 수있는 고유 한 헤더 키 를 생성합니다. 많은 프록시는 인식하지 못하는 이름으로 헤더를 제거합니다.
즉, Authorization:쿠키가 사용자 지정 값을 전달하도록 명시 적으로 설계 되었기 때문에 쿠키가 명시 적으로 사용자 지정 값을 전달하도록 설계 되었기 때문에 쿠키를 사용하여 토큰을 전송하는 것이 더 나은 생각 일 수 있지만 HTTP의 내장 인증 메서드에 대한 사양은 실제로 어느 쪽이든-그것이 말하는 것을 정확히 보고 싶다면 여기를보세요 .
이것에 대한 또 다른 점은 많은 HTTP 클라이언트 라이브러리가 Digest 및 Basic auth를 기본적으로 지원하지만 헤더 필드에 원시 값을 설정하려고 할 때 삶을 더 어렵게 만들 수 있지만 모두 쿠키를 쉽게 지원하고 그 안에 더 많거나 적은 가치를 허용하십시오.
Authorization:헤더 사용)의 범위는 도메인 당입니다. 즉, 쿠키 도메인을 "이 도메인"으로 설정하고 경로를 "/"로 설정하면 HTTP 인증과 동일한 범위를 갖게됩니다. 그러나 그것은 당신에게 달려 있습니다. 그러나 Julian Reschke가 지적했듯이, 당신 feel that you have something of generic use이 다른 애플리케이션에서 사용될 수있는 것 외에는 새로운 인증 체계를 정의해서는 안됩니다 .
CROSS ORIGIN 요청 의 경우 다음을 읽으십시오.
나는이 상황에 직면했고 처음에는 Authorization헤더 를 사용하기로 선택했고 나중에 다음 문제에 직면 한 후 제거했습니다.
Authorization헤더는 사용자 정의 헤더로 간주됩니다. 따라서 AutorizationHeader 세트를 사용하여 교차 도메인 요청이 이루어 지면 브라우저는 먼저 프리 플라이트 요청을 보냅니다 . 실행 전 요청은 OPTIONS 메서드에 의한 HTTP 요청이며,이 요청은 요청에서 모든 매개 변수를 제거합니다. 서버 Access-Control-Allow-Headers는 사용자 정의 헤더 ( Authorization헤더) 의 값을 갖는 헤더 로 응답해야합니다 .
따라서 클라이언트 (브라우저)가 보내는 각 요청에 대해 추가 HTTP 요청 (OPTIONS)이 브라우저에 의해 전송되었습니다. 이로 인해 API 성능이 저하되었습니다. 이것을 추가하면 성능이 저하되는지 확인해야합니다. 해결 방법으로 http 매개 변수로 토큰을 보내고 있는데, 이것이 최선의 방법은 아니지만 성능을 타협 할 수는 없습니다.
Authorization token내 애플리케이션에 내 (민감한 데이터)를 사용하여 사용자를 인증해야했습니다 . 같은 이유로 GET에서 민감한 데이터를 보내지 않아야하며 params에 인증 토큰을 사용해서는 안됩니다. w3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3에 따라 "HTTP 프로토콜은 민감한 데이터의 제출을 위해 GET 기반 양식을 사용해서는 안됩니다 ".
이것은 약간 구식이지만 같은 질문에 대한 답을 찾는 다른 사람들이있을 수 있습니다. API에 적합한 보호 공간이 무엇인지 생각해야합니다. 예를 들어 API에 대한 클라이언트 애플리케이션 액세스를 식별하고 인증하여 알려진 등록 된 클라이언트 애플리케이션으로의 사용을 제한 할 수 있습니다. 이 경우 다음을 사용할 수 있습니다.Basic클라이언트 식별자를 사용자 ID로 사용하고 클라이언트 공유 비밀을 암호로 사용하는 인증 체계. 독점 인증 체계가 필요하지 않으며 각 보호 공간에 대해 클라이언트가 사용할 것을 명확하게 식별하기 만하면됩니다. 각 보호 공간에 대해 하나만 선호하지만 HTTP 표준은 각 WWW-Authenticate 헤더 응답에 대한 다중 인증 체계와 각 응답에 여러 WWW-Authenticate 헤더를 모두 허용합니다. 이것은 어떤 옵션을 사용할지 API 클라이언트에게 혼동을 줄 것입니다. 일관성 있고 명확해야 API가 사용됩니다.
사용자 지정 체계 이름과 함께 HTTP 인증을 사용하지 않는 것이 좋습니다. 일반적으로 사용하는 것이 있다고 생각되면 새로운 체계를 정의 할 수 있습니다 . 자세한 내용은 http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 을 참조하십시오.
우편 배달부에서 친절하게 아래에서 시도하십시오 :-
헤더 섹션에서 예제는 나를 위해 작동합니다 ..
인증 : JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU
that article full of misleadings, a lot of his points does not make sense어떤 식 으로든 등 (의미, 그것은 아마 여기 코멘트를 넘어 뭔가). 답변이나 블로그 게시물을 작성할 수 있습니까? 논쟁을 비교하는 것은 정말 흥미로울 것입니다.