01 01

OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름과 같이 개념적인 부분을 서술한 문서입니다. OAuth 2.0은 클라이언트 또는 제 3자 애플리케이션이 사용자의 비밀번호를 직접 알지 않고도, 사용자를 대신해 정보에 접근할 수 있도록 권한을 위임하는 프로토콜입니다.e.g. 넷플릭스 계정을 구글 계정으로 로그인할 때 구글에 비밀번호를 입력하지만 넷플릭스는 구글 비밀번호를 모릅니다. 구글에서 인증된 사용자로 토큰Token을 발급해주면, 넷플릭스는 그 토큰 정보를 확인하고 로그인을 시켜줍니다.OAuth 2.0의 주요 컴포넌트Resource Owner, Client, Authorization Server, Resource Server Resource Owner(자원 소유) : ..

세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 간단히 정리한 글입니다. HTTP 프로토콜은 Stateless 합니다. Stateless 하다는 건, 서버에게 가는 각각의 요청이 서로에게 영향을 끼치지 않고 독립적으로 이루어진다는 뜻입니다. 즉, 첫 번째 요청의 응답을 두 번째 요청과 공유하지 않는다는 거고, 이 말인즉슨 요청마다 우리가 누구인지 서버에게 알려줘야 한다는 것입니다. "서버에게 이 요청을 보낸 자가 누구인지 알려줌"을 할 때, 세션 기반 인증, 토큰 기반 인증 방법을 이용합니다. 세션 기반 인증KEYWORD : Session DB, Session ID, 쿠키 사용자가 로그인하면, 서버가 Session DB에 해당 유저의 Session ID를 생성하여 저장합니다...

테스트할 때 이용되는 Mockito의 간단 개념을 다른 Java Mock 라이브러리와 비교해서 설명하고, Mockito의 Mock, Stub, Spy 개념을 정리한 글입니다.  Mockito란?   Mockito는 모의 객체(Mock)을 만드는 라이브러리 중 하나입니다.Java Mocking 분야에는 EasyMock, jMock 같은 expect-run-verify(예상-실행-검증)방식을 따르는 라이브러리가 있습니다. EasyMock 은 expect 단계에서 "이 메소드는 n번 호출되어야 한다.", "이 메소드는 호출 후에 특정 값이 반환되어야 한다." 와 같은 예상안을 작성해두고, verify 단계에서 expect 단계에 작성해둔 예상안을 한 번에 검증합니다.반면 Mockito 는 expect 라는 개..

Index1. 입력값 검증(Input Validation) 이란?2. 입력값 검증을 각 계층별로 진행해야 하는 이유3. 중복 검증과 안전성의 트레이드 오프4. 계층별 검증 범위와 판단 기준이전에 작성한 데이터 검증(Vallidation)을 어디에서 해야하는가 와 같은 주제로, 추가적으로 필요한 정보를 보충하고 정리했습니다. 입력값 검증(Input Validation) 이란?프로그램에 입력된 데이터가 예상한 형식과 조건을 만족하는지 확인하는 과정입니다.  입력값 검증을 각 계층별로 진행해야 하는 이유단일 계층에서 입력값을 검증하기 보다 각 계층별마다 검증하는 것이 권장되는 이유는 다음과 같습니다. 데이터 분석 관점이 다르다 :각 계층은 하나의 데이터를 두고 다른 관점에서 분석합니다.때문에 검증해야할 항목이..

개발자 도구에서 Network 탭을 클릭한다.상단 필터에서 "XHR" 또는 "Fetch/XHR" 선택한다. (API 요청만 필터링)새로고침(F5 or Ctrl + R)하면 API 요청이 나온다.요청을 클릭하면 아래에 요청(Request) / 응답(Response) / 헤더(Headers) 등을 볼 수 있다.   Preserve log 체크하면 페이지 새로고침해도 로그 유지된다.Disable cache 체크하면 캐시 없이 매번 새 요청 보내기 가능하다.Filter에 api 같은 키워드 입력해서 원하는 요청만 찾을 수 있다.

사전 지식 :API, https://j00d.tistory.com/36웹 API에 대해 이해하기 위해 작성한 짧은 글입니다. 웹 API의 개념웹 API는 웹 서버나 웹 브라우저 간를 위한 API입니다. 여기서 "나"(or)라고 표현하는 이유는, 웹 서버를 위한 API일 수도 있고 웹 브라우저를 위한 API일 수도 있기 때문입니다.  웹 서버를 위한 웹 API, 즉 서버 사이드 웹 API에 대해 정의하자면, HTTP* 기반 웹 서버와 클라이언트가 JSON/XML형태의 메세지를 주고 받는 인터페이스**입니다.서버 사이드 웹 API의 흐름을 간단 설명하자면, 다양한 클라이언트***가 서버에게 데이터를 요청하고 서버는 요청에 대해 응답합니다. * Hypertext Transfer Protocol, 웹 브라우저와..

사전 지식 : 웹 API, https://j00d.tistory.com/37 웹 API인 SOAP와 REST의 차이점을 표로 정리하고 SOAP에서 REST로 전환한 이유에 대해 작성한 짧은 글입니다. SOAP와 REST 차이점 특징 SOAPREST프로토콜HTTP, SMTP, JMS, FTP 등 여러 프로토콜주로 HTTP*메시지 포맷XMLJSON, XML 등 다양한 포맷 가능구조복잡한 XML 기반, 엄격한 규격단순하고 직관적, 규격이 자유로움상호운용성다양한 시스템 간의 호환성 제공HTTP 기반이라 웹 시스템 간에 매우 적합캐싱 지원기본적으로 지원하지 않음HTTP의 캐싱 기능을 활용 가능보안WS-Security 등의 복잡한 보안 지원HTTP 자체의 보안(SSL/TLS)을 사용상태상태 유지(세션 기반)상태 비..

웹 서버(Web Server)와 웹 애플리케이션 서버(Web Application Server, WAS) 의 차이를 Application이란 단어를 중점으로 비교합니다.웹 애플리케이션 서버(Web Application Server, WAS)의 구조도를 보고, 웹 애플리케이션 서버(Web Application Server, WAS)안에 웹 서버(Web Server)가 있음을 확인한 후웹 서버(Web Server)와 웹 애플리케이션 서버(Web Application Server, WAS)를 분리하는 이유에 대한 이야기를 추가적으로 합니다.최종적으로 웹 서버(Web Server)와 웹 애플리케이션 서버(Web Application Server, WAS)의 종류를 확인한 후 마무리되는 문서입니다.  1. 웹 서..