OAuth 응답 및 세션 처리

Question

OAuth2 토큰 교환이 끝나면 필드 I이있는 구조체 (예 : GoogleUser)로 비 정렬 화 된 사용자 데이터의 JSON 배열이 [일반적으로] 남아 있습니다. 신경 써.

내 DB에 데이터를 기록하는 합리적인 방법은 무엇입니까? 콜백 처리기에서 CreateUser 함수를 호출하고 구조체를 전달한 다음 사용자가 이미 DB에 존재하지 않는지 확인한 후 저장하십시오.

콜백 핸들러에 세션 토큰 (예 : session.Values["authenticated"] == true)을 생성하고 쿠키에 적절한 만료일을 저장하고 로그인 한 상태의 모든 처리기 함수에 대해 if authenticated == true을 확인한다고 가정합니다 사용자? 또는 관리자 핸들러의 경우 : if admin_user == true. 여기에 어떤 위험이 있습니까? HTTPS를 통해 보안 쿠키를 사용하고 있다고 생각하십니까?

기본 질문에 사과 : 그냥 "베스트 프랙티스"방법으로 사용자를 w/OAuth로 로그인하는 방법을 알아 내려고합니다.

Answer 1

첫 번째 질문에 관해서는 일반적으로 단일 거래로 수표를 넣고 삽입하는 것이 좋습니다.사용하는 DB에 따라 다르지만 일반적으로 UPSERT 문이라고합니다.

두 번째 질문에 관해서

CREATE FUNCTION upsert_user(emailv character varying, saltv character varying, hashv character varying, date_createdv timestamp without time zone) RETURNS void 
    LANGUAGE plpgsql 
AS $$; 
BEGIN 
    LOOP 
     -- first try to update the key 
     UPDATE users SET (salt, hash) = (saltv, hashv) WHERE email = emailv; 
     IF found THEN 
      RETURN; 
     END IF; 
     -- not there, so try to insert the key 
     -- if someone else inserts the same key concurrently, 
     -- we could get a unique-key failure 
     BEGIN 
      INSERT INTO users(email, salt, hash, date_created) VALUES (emailv, saltv, hashv, date_createdv); 
      RETURN; 
     EXCEPTION WHEN unique_violation THEN 
      -- do nothing, and loop to try the UPDATE again 
     END; 
    END LOOP; 
END; 
$$; 

, 일반적으로Secure 쿠키를 HTTPS 충분 이상 : PLSQL에서는이 같은 비트 (맛 수정) 보인다. HttpOnly 옵션을 설정하고 일반적으로 Path 옵션도 설정합니다.

HttpOnly은 JS (HTTP 또는 HTTPS 만 해당)에서 쿠키에 액세스 할 수없고 Path 옵션을 사용하면 쿠키의 유효 경로 (URL)를 지정할 수 있음을 나타냅니다.

Answer 2

Access TokenOAuth 표준에는 만료 날짜가 있습니다. 대개 인증 서버가 결정합니다. 귀하의 경우에는 인증 서버 측에 있다고 가정합니다.

읽기 예 RFC 6750는 :

일반적 베어러 토큰 anOAuth 2.0 [RFC6749] 액세스 토큰 응답의 일부로서, 클라이언트로 복귀된다. 이러한 반응의 예는 다음

가

HTTP/1.1 200 OK 
Content-Type: application/json;charset=UTF-8 
Cache-Control: no-store 
Pragma: no-cache 

{ 
    "access_token":"mF_9.B5f-4.1JqM", 
    "token_type":"Bearer", 
    "expires_in":3600, 
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" 
} 

또한 RFC 6749에 Access Token의 개념을 읽는다

가

액세스 토큰 다른 인증 구조 (예를 들어, 사용자 이름과 비밀번호를 교체 추상화 계층을 제공한다) 리소스 서버에 의해 이해되는 단일 토큰. 이 추상화를 사용하면 액세스 토큰을 발급 할 때 인증 부여 을 사용하는 것보다 더 제한적일뿐만 아니라 다양한 인증 방법을 이해하기 위해 리소스 서버의 필요성을 제거 할 수 있습니다.

그래서 귀하의 경우에는 "쿠키"또는 "관리 처리기"가 필요하지 않다고 생각합니다. OAuth spec과 같이 로그인 한 각 사용자에 대해 Access Token & Refresh Token을 생성하고 만료도 저장해야합니다. Access Token과 관련된 해시 방법을 제공하여 법적 요청인지 확인할 수도 있습니다. 예를 들어 사용자는 자신의 액세스 토큰을 사용하여 해시 & 소금 메서드를 사용하여 서명을 생성하고 액세스 토큰 & 서명을 서버에 보내 확인합니다. 자세한 내용은 Public Key Encryption을 참조하십시오.

또한 이러한 토큰은 모두 임시 리소스이므로 DB에 저장할 필요가 없습니다. 모든 사용자 정보를 메모리에 저장하고 캐시 레이어를 구현하여 DB에 진정 중요한 정보 (현재 현재 사용하고있는 정보)를 DB 압력을 낮추기 위해 저장할 수 있습니다.