# 인증

de24world

워드프레스란? 워드프레스는 웹사이트와 블로그를 만들고 관리하는 데 사용되는 무료 오픈 소스 컨텐츠 관리 시스템(CMS)입니다. 이것은 전 세계적으로 많은 웹사이트 운영자와 블로거에게 인기가 있는 도구 중 하나입니다. 워드프레스를 사용하면 웹사이트를 손쉽게 만들고 내용을 업데이트하며 다양한 디자인 및 기능을 추가할 수 있습니다. 또한 사용자 친화적인 인터페이스와 다양한 플러그인, 테마, 위젯 등을 통해 원하는 웹사이트를 만들 수 있습니다. 워드프레스는 비즈니스 웹사이트, 블로그, 온라인 매장, 포트폴리오, 뉴스 사이트 등 다양한 종류의 웹사이트를 만들 수 있는 다재다능한 도구입니다. [원본 링크](https://pusha.tistory.com/entry/%EC%9B%8C%EB%93%9C%ED%94

inseo24

대상 Spring Authorization Server 를 이용해 인가 서버를 구축하려는 개발자 목적 공식 문서를 읽고 핵심부터 이해하자. 순서 RegisteredClient, OAuth2Authorization, OAuth2AuthorizationConsent <- 여기까지 OAuth2Token Context Generator Customizer SessionRegistry RegisteredClient 앞서 OAuth 2.0 스펙 글에서 Client에 대해 말한 적이 있다. `Spring Autho

mallang

📍 GitHub 바로가기 1 JWT 설계 1️⃣ JWT dependency 2️⃣ SecretKey → application.properties 3️⃣ JwtUtil.java import org.springframework.beans.factory.annotation.Value; → @Value import문 수정적용 2 JWT적용 설계 > 로그인성공 → HTTP Response Header에 JWT Token 생성 후, 실어 Client에게 보냄 1️⃣ UserController.java 2️⃣ UserService.java 3 JWT인가 설계 1️⃣ 관심상품 조회 📍 ProductController.java 📍 ProductService.java 2️⃣ 관심상품 등록 📍 Prod

inseo24

대상 Spring Authorization Server 를 이용해 인가 서버를 구축하려는 개발자 목적 > Spring Authorization Server 로 인가 서버를 구축하자. 뭐부터 해야 할까? 우선 문서부터 읽어야 하지 않을까? 여러 개의 문서가 있는데 필요한 내용부터 우선 가볍게 읽었다. 기본적인 내용을 이해하기 위해 좋은 순서가 어떻게 될지 생각해 봤다. Spring Authorization Server 공식 문서 페이지 ![How-to Guides 에 나오는 추가 가이드 리스트](https://velog.velcdn.com/images/inseo24/post/2c

mallang

1 쿠키와 세션 1️⃣ Client를 구별하지 못하는 HTTP > 📌 Stateless : HTTP 프로토콜은 상태를 저장하지 않음 (리소스절약을 위함) Client GET Request에 대해, Response를 받을 때까지 → 하나의 HTTP Request 하지만 Stateless 특성상, 웹 서버는 1번과 2번이 같은 Client Request인지 구별 ❌ 쿠키 + 세션 → HTTP에 상태정보를 유지하기위해 사용됨 Stateful 서버에서 Client 별 인증 및 인가 가능 ✅ 2️⃣ 쿠키 > 📌 쿠키 : Client에 저장될 목적으로 생성한 작은 정보를 담은파일

inseo24

목적 스프링 코드로 인가 코드 요청 플로우를 이해해보자 Spring Authorization Server 기억하기로 작년 말에 더 이상 지원하지 않는다는 소식이 들렸다가 다시 지원하기 시작한 Spring Authorization Server 프로젝트다. 이 글에선 1.1.1 버전을 기준으로 설명한다. 코드를 보기 전에, 인가 코드 요청 흐름을 요약하면 아래와 같다. 인가 코드 요청 필수 : client-id, redirect-uri, response-type=code 선택 : scope 등 미인증 상태라면 로그인 페이지로 이동 사용자 로그인 및 인가 코드 재요청 동의 페이지로 이동 클라이언트가 사용자의 정보 사용을 요구하고, 해당 사용자가 미동의 상태면 동의 페이지로 이동 동의받기 인가 코드 반환 인가 코드 요청 시점에 보낸 redirect_uri로

mallang

📍 GitHub 바로가기 1 User 설계 1️⃣ entity > User.java 2️⃣ entity > UserRoleEnum.java 3️⃣ repository > UserRepository.java 2 UserDto 설계 1️⃣ dto > SignupRequestDto.java 2️⃣ dto > LoginRequestDto.java 3 회원가입 설계 1️⃣ controller > UserController.java 2️⃣ service > UserService.java 3️⃣ repository > UserRepository.java 4 로그인 설계 1️⃣ controller > UserController.java 2️⃣ service > UserSe

dlzlqlzl

영어도 비슷하고 의미도 유사한 것 같고 늘 헷갈리는 경우가 많았는데 이번 기회에 인증과 인가를 확실하게 구분지어 정리하고 넘어가 보려고 합니다. 인증(Authentication)과 인가(Authorization) 인증(Authentication) 인증은 해당 유저가 실제 유저인지 인증하는 개념입니다. FaceId, 웹사이트 로그인 등, 실제로 그 유저가 맞는지 확인하는 절차를 의미합니다. 인가(Authorization) 인가는 해당 유저가 특정 리소스에 접

mallang

1 인증과 인가 |구분|의미| |:---:|---| |인증(Authentication)|- 해당 User가 실제 User인지 인증하는 개념 - 스마트폰 지문인식, 사이트 로그인 등| |인가(Authorization)|- 해당 User가 특정 Resource에 접근가능한지 허가를 확인하는 개념 - 관리자페이지, 관리자권한 등| Spring에서 인증&인가 → Spring Security 2 인증의 방식 1️⃣ 웹 어플리케이션인증 특수성 Server - Client 구조 Http 통신 프로토콜 사용 → 비연결성(Connectionless) + 무상태(Stateless) 위의 두가지 특성때문에 url을 계층적으로 설계함

inseo24

목적 OAuth 2.0 인가 프레임워크 이해 대상 인증, 인가, OAuth 2.0에 대해 처음 접하는 사람 기본 개념 인증 회사원이라면, 혹은 드라마에서 흔히 회사원들이 출근할 때 이런 게이트에 회사 ID 카드를 찍고 입장하는 것을 보실 수 있습니다. 이게 인증입니다. 회사에선 자사의 사원임을 인증하는 목적으로 회사 ID 카드를 발급해줍니다. ID 카드로 그 회사의 사람인 것을 보증하는 것이죠. 카드 찍고 지나가는 게이트 사진 인가 회사의 모든 사람이 동일한 권한이 있는 게 아닙니다. 사원이 CEO 방을 마음대로 들어갈 수 없는 것처럼 말이죠. 특정 지위를 가진 사람만 접근할 수 있겠죠. 이게 인가입니다. 인증이 된 사용자는 자신이 사용할 수 있는 것이

glencode

서론 안녕하세요. 페스타고에는 다양한 역할의 사용자가 존재합니다. 이렇게 다양한 역할의 사용자가 있다면 사용자의 역할에 맞는 인증과 인가 작업이 필요합니다. 단순히 역할에 따른 구분이라면 큰 문제가 없겠지만, 다양한 사용자들이 접속하는 환경에서 인증을 하는 방법에서 차이로 인해 문제가 발생했습니다. 어떠한 문제점에 직면했고, 이것을 어떻게 해결했는지 설명하겠습니다. 본론 페스타고는 축제의 공연에 대한 티켓팅을 오프라인으로 기다리지 않고 온라인으로 편하게 예매하고 빠르게 출입을 가능하게 해주는 서비스입니다. 잠깐 저희 서비스의 흐름에 관해 이야기를 해보겠습니다. 사용자가 공연에 대해 티켓을 예매하려고 합니다. 이때, 사용자가 티켓을 예매하려면 우선 공연과 축제가 생성되어 있어야 합니다. 그렇다면 공연과 축제는 티켓을 예매하는 사용자가 생성을 하는 것일까요? 공연과 축제를 생성하는 것은 티켓을 예매하는 사용자가 아닌, 축제와 공연을 개최하고 싶은 관리자입니

juh518

인증 (Authentication) 인증은 사용자나 시스템이 자신이 주장하는 신원(identity)이 실제로 누구인지 확인하는 과정을 말한다. 사용자가 시스템에 로그인하거나 액세스하려고 할 때, 시스템은 해당 사용자가 실제로 누구인지를 확인하기 위해 인증을 수행한다. 이를 위해 다양한 방법이 사용될 수 있으며, 주로 다음과 같은 인증 요소가 사용된다. 사용자명, 비밀번호 가장 일반적으로 사용되는 인증 방법으로, 사용자는 자신의 식별 정보와 암호를 제공하여 신원을 확인한다. 바이오매트릭 데이터 생체 인식 기술을 사용하여 지문, 안면, 홍채 등의 생체적 특징을 인식하여 사용자를 인증하는 방법이다. 멀티팩터 인증 둘 이상의 인증 요소를 조합하여 보다 강력한 인증을 제공하는 방법이다. (예) 비밀번호와 SMS로 전송되는 일회용 코드의 조합 등 > 인증은 사용자의 신원을 확인하여 시스템에 접근을 허용하거나

wodnr_09

이전까지 공지 게시글, 관리비 장부를 마무리 했다고 생각했지만 한 가지 빠뜨린 요구사항이 있었습니다. > >같은 건물 코드를 공유하고 있는 관리자와 사용자만이 글과 장부를 조회할 수 있어야 한다는 것을 구현해야 했고, 이 때문에 일부 로직을 수정했습니다. > > 추가적으로 일반 사용자는 카카오 로그인만으로 사용자 인증을 할 수 있다는 기능을 추가 해보았습니다. 📌 일부 로직 수정 요구 사항 같은 건물 코드를 공유하고 있는 관리자와 사용자만 공지 글과 관리비 장부를 조회할 수 있어야한다. 위 요구 사항을 충족 시키기 위해서 핵심은 다음과 같습니다. 관리자는 건물 고유 코드를 가지고 있어야 함. 공지 게시글과 관리비 장부를 조회하는 로직에서는 사용자의 건물 고유 코드를 확인하는 과정이 필요. 이를 코드로 구현하기 위해 먼저 관리자 회원가입 로직을 수정했습니다. 관리자 회원가입 시 요청 받은 건물의 이름을 `genera

jiiina

📍 구글 서비스 등록 >먼저, 구글 API 콘솔 사이트에서 Client Id와 Client Secret을 발급받자! 새 프로젝트 생성 동의화면 구성 동의화면 구성 탭에서는 외부를 선택해서, Google 계정이 있는 모든 테스트 사용자가 사용할 수 있도록 한다. 이후 필수 항목들을 채워 완료하면 된다. 앱 이름 : 구글 로그인시 사용자에게 노출될!! 앱 이름 사용자 지원 이메일 : 사용자 동의 화면에서 유저에게 노출될!! 이메일 주소 (help

wuchangs

JWT JWT는 . 을 구분자로 3가지의 문자열로 구성된다. 헤더(header), 내용(payload), 서명(signature)로 구성 header alg 와 typ 으로 구성 typ 값은 jwt로 고정 alg는 3번째 verify signature 값을 만드는데 사용될 알고리즘이 지정된다. 대표적으로 HMAC, SHA256, RSA 알고리즘이 있음. payload 토큰에 담을 정보들이 들어있음. 각 정보들을 '클레임' 이라고도 함. sub: 토큰의 제목 iss: 토큰 발급자 aud: 토큰 대상자 exp: 토큰의 만료시간. 시간은 NumericDate 형식으로 되어있어야 하며 언제나 현재 시간보다 이후로 설정되어 있어야 한다. iat: 토큰이

ranjeler

오늘은 인증과 인가의 차이 에 대한 내용을 정리해 봤습니다. 서로 비슷해보이는 개념이라서 그런지 설명하기 애매햇던 내용인데 인증과 인가에 대해 제대로 알아보려고 합니다. 1.인증이란 > 인증은 접속한 유저의 신원을 확인하는 것을 인증(Authentication)이라 한다 > 1-인증의 예시 id password를 통해 로그인 하는 경우 오프라인에서는 신분확인을 위해 신분증을 보여주는 행위 휴대폰을 통해 인증번호를 받는 행위 사이트를 이용하기 위해 회원가입을 하는 경우 2-인증의 과정(네이버 로그인시) 1.회원가입을 한다→회원가입시 비밀번호 암호화 후 db에 저장 2.로그인을 한다 → 로그인시 입력한 비밀번호를 다시 암호화해 db에 있는 정보와 일치하는지 확인 3.일치하면 인증 완료 불 일치시 로그인 실패 2.인가란 > 인가는 인증된 사용자가 시스템의 *

more

Bean Bean을 수동으로 등록하는 방법 자동 등록 @Component를 사용하면 @ComponentScan에 의해 자동으로 스캔되어 해당 클래스를 Bean으로 등록 프로젝트의 규모가 커질 수록 등록할 Bean들이 많아지기 때문에 자동등록을 사용하면 편리 비즈니스 로직과 관련된 클래스들은 그 수가 많기 때문에 @Controller, @Service와 같은 애너테이션들을 사용해서 Bean으로 등록하고 관리하면 개발 생산성에 유리 -> 정리 : 처리해야할 로직과 클래스가 많아져 여러 Bean들을 등록해야하기 때문에 일반적으로는 자동 등록하는 것 수동 등록 : 기술적인 문제나 공통적인 관심사를 처리할 때 사용하는 객체들을 등록할 때 사용 공통 로그처리와 같은 비즈니스 로직을 지원하기 위한 부가적, 공통적인 기능들을 기술 지원 Bean이라 부르고 수동등록 비즈니스 로직 Bean 보다는 그 수가 적기 때문에 수동으로 등록하기 부

moka81

가트너는 “2022년부터 API 남용이 가장 빈번한 공격 경로로 대두”할 것이라고 예측했고, 이는 현실이 되었습니다. 아카마이나 씨디네트웍스 등 주요 IT 업체들도 API 보안에 크게 주목하고 있습니다. 개발자들이 API 키를 하드코딩하는 일은 흔히 있는 일이지만(^^), 최근에는 챗GPT 열풍과 함께 API 보안 이슈가 다뤄지기도 했습니다. 사이버 범죄자들, 오픈AI API 키 스크랩해서 GPT4를 무허가로 사용한다 링크텍스트 현재 웹에서 돌아가는 거의 모든 애플리케이션이 API를 사용한다고 해도 과언이 아닙니다. 덕분에 사용자들은 더 편리하게 서비스를 이용할 수 있게 되었습니다. 아카마이에 따르면 이미 2019년에 API 트래픽이 당사 전체 트래픽의 83%를 차지했다고 합니다. 이렇게 사용량이 크게 늘며 ‘공격 표면’이 넓어져 많은 공격을 받게 되었지만, 단시간에 성장하다 보니

seongwop

유저 인증/인가 방식에 대표적인 키워드 쿠키, 세션과 토큰을 알아보고자 한다. ❗이 세 가지 인증 방식은 서로를 완전히 대체하기 위해 나온 방식들이 아니다. 예를 들어, 인증/인가에 쿠키만 사용할 수도 있고, 세션 & 쿠키, 토큰 & 쿠키 이런 식으로 조합되어서도 사용할 수 있다. 보안 문제로 인해 쿠키만으로 인증/인가를 해결하는 경우는 거의 없지만, OAuth를 제외하고 상황에 따라 세션 방식 vs 토큰 방식으로 나뉘는 경우가 많으며 토큰과 함께 사용되는 쿠키 또한 Local Storage, Session Storage 등 다른 저장소로 대체되는 경우도 많기 때문에 각각의 방식을 이해하는 것이 중요하다. > ### 쿠키 (Cookie) 서버로부터 전송받고 브라우저에 저장되는 key-value 형식의 데이터 조각 쿠키 기반 인증은 브라우저에 유저 정보를 저장 애초에 쿠키가 필요하게 된 핵심적인 이유는 바로 *HTTP 프로토콜의 무상태성(Stateless)

hi_nahyun

* CI (Connection Information) 88byte 일방향 암호화. 개인 고유 식별키 인증업체, 인증방법 등과 관계없이 개인에게 고유하게 부여되는 온라인상 주민등록번호. 주민등록번호를 추정불가하게 암호화한 값. 예시 값 : 2f0c8e1d4d5e53078d5ee6b7544201f88c3f19102f0c8e1d4d5e53078d5ee6b7544201f88c3f19108c3f1910 국민당 1개의 고유한CI를 가지며, 이는 주민등록번호가 변경되지않는 한 변경되지않는다. > * DI (Duplication Information) 66byte 사이트별 개인 고유 식별키 인증업체 혹은 인증되는 PG사의 상점아이디별로 달라지는 개인 고유번호. 주민등록번호와 사업자고유번호를 암호화한 값 예시 값 : e0977ac6b52f6e831c886c4b57aa187b1057dc9a62a7ab3d7752a6ec45dedb5d5d 한 사이트 내에서의 동일인의 중복가입을 체크하기 위해 사