회사의 규모가 커지면, 이때 회사가 당신에게 기술 도킹을 하기 시작할 수도 있고, API 인터페이스를 제공할 수도 있습니다. 이때 API 인터페이스의 보안을 어떻게 설계하고 보장해야 할까요?
가장 일반적으로 사용되는 시나리오에는 두 가지 주요 유형이 있습니다.
여기서 토큰 스키마는 웹에서 가장 널리 사용되는 인터페이스 인증 체계입니다. 앞서 문장' JWT 를 사용하여 싱글 사인온을 실현하는 방법을 가르쳐 준다' 는 글을 썼던 기억이 납니다. 관심있는 친구가 볼 수 있습니다. 몰라도 괜찮아. 여기에 토큰 방안을 간단히 소개하겠습니다.
위 그림에서 토큰 체계의 구현은 주로 다음 단계로 구성되어 있음을 분명히 알 수 있습니다.
실제 사용 중 사용자 로그인이 성공하면 결과 토큰은 redis 저장 시 시간 제한이 있으며 일반적으로 2 시간으로 설정되며 2 시간 후 자동으로 만료됩니다. 이때 다시 로그인하여 유효한 토큰을 다시 받아야 합니다.
Token 방안은 현재 업무 유형에서 가장 널리 사용되는 방안으로 실용성이 뛰어나 해커가 가방을 잡고 데이터를 수집하는 것을 효과적으로 막을 수 있다.
하지만 토큰 스키마에도 몇 가지 단점이 있습니다! 가장 분명한 것은 당신이 제 3 자 회사와 인터페이스할 때, 당신의 인터페이스 요청이 매우 클 때, 이 때 token 이 갑자기 효력을 상실하고, 대량의 인터페이스 요청이 실패할 수 있다는 것입니다.
이에 대해 나는 깊이 체득했다. 아주 일찍, 제가 중대형 인터넷 회사와 디버깅을 하고 있을 때, 그들이 제게 제공한 인터페이스 도킹 방안은 token 방안이었던 것을 기억합니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 가족명언) 당시 우리 회사의 유량이 최고조에 달했을 때, 나는 그들의 인터페이스에 대량의 착오를 보고하게 했다. 그 이유는 토큰이 실패했기 때문입니다. 토큰이 실패하면 토큰 인터페이스를 새로 고치기 위해 호출됩니다. 새로 고침이 완료되면 토큰 만료에서 토큰 새로 고침까지의 시간 간격 동안 많은 실패 요청이 발생할 수 있으므로 실제 API 도킹 과정에서 토큰 스키마를 사용하지 않는 것이 좋습니다.
이름에서 알 수 있듯이 인터페이스 서명은 몇 가지 서명 규칙을 통해 매개변수를 서명한 다음 서명 정보를 요청 헤더에 넣는 것입니다. 서버가 클라이언트로부터 요청을 받으면 설정된 규칙에 따라 해당 서명 문자열을 생성하고 클라이언트의 서명 정보와 비교하기만 하면 됩니다. 일치하는 경우 업무 프로세스 프로세스를 시작합니다. 통과하지 못하면 서명 유효성 검사에 실패했다는 메시지가 표시됩니다.
인터페이스 서명 체계에는 네 가지 핵심 매개 변수가 있습니다.
여기서 서명 생성 규칙은 두 단계로 나뉩니다.
매개 변수 2 의 암호화된 결과는 우리가 원하는 최종 서명 문자열입니다.
인터페이스 서명 체계, 특히 많은 수의 인터페이스 요청의 경우 여전히 매우 안정적입니다.
즉, 인터페이스 서명을 토큰 스키마를 보완하는 것으로 간주할 수 있습니다.
그러나 인터페이스 서명 체계를 프런트 엔드 도킹으로 확장하려는 경우 대답은' 적합하지 않다' 입니다.
서명 계산은 매우 복잡하기 때문에, 둘째, 앱 시크릿을 쉽게 누설할 수 있다!
이렇게 많이 말했으니, 프로그램과 함께 연습하자!
앞서 언급했듯이 토큰 체계의 핵심은 사용자가 로그인에 성공하면 적절한 토큰을 생성하여 프런트엔드로 반환하면 다음 번에 비즈니스 인터페이스를 요청할 때 토큰을 가져와야 한다는 것입니다.
구체적인 방법도 두 가지로 나눌 수 있습니다.
다음으로 두 번째 구현을 소개합니다.
먼저 jwt 도구를 작성합니다.
그런 다음 로그인할 때 토큰을 생성하여 클라이언트에 반환합니다.
마지막으로 통합 인터셉터를 작성하여 클라이언트가 들어오는 토큰이 유효한지 확인합니다.
토큰을 생성할 때 토큰에 사용자 ID, 사용자 이름 등과 같은 몇 가지 기본 사용자 정보를 저장할 수 있습니다. 이렇게 하면 토큰이 인증된 후 내부 정보를 구문 분석하기만 하면 해당 사용자 ID 를 얻을 수 있으므로 데이터베이스에서 몇 가지 기본 정보를 조회할 필요가 없습니다.
동시에 사용 과정에서 민감한 정보를 저장하지 않도록 노력하십시오. 해커에 의해 쉽게 분석될 수 있기 때문입니다!
마찬가지로, 서버 인증의 관점에서, 우리는 먼저 서명 인터셉터를 작성하여 클라이언트가 들어오는 매개 변수가 합법적인지 확인할 수 있으며, 한 가지가 불법이면 오류를 알려 줄 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 남녀명언)
구체적인 코딩 방법은 다음과 같습니다.
서명 도구 클래스 서명:
서명 계산은 hamc 방법으로 변경할 수 있으며 아이디어는 기본적으로 동일합니다.
위의 토큰 및 인터페이스 서명 체계는 제공된 인터페이스를 보호하여 다른 사람이 요청을 조작하거나 요청을 시뮬레이션하지 못하도록 합니다.
그러나 데이터 자체에 대한 보안이 부족합니다. 즉, 요청된 매개변수와 반환된 데이터는 다른 사람이 가로채고 일반 텍스트일 수 있으므로 가로채기만 하면 해당 비즈니스 데이터를 얻을 수 있습니다.
이 경우 요청 및 반환 매개 변수 (예: RSA, AES 및 기타 암호화 도구) 를 암호화하는 것이 좋습니다.
또한 프로덕션 환경에서는 https 를 사용하여 전송하면 보안 기능이 뛰어납니다!