Spring Boot로 만드는 OAuth2 시스템 3
API 서버 만들기
API 서버 만들기
OAuth2 인증을 받기 위한 API 서버를 간단하게 만들어보겠다.
API 서버 자체는 OAuth2 독립된 시스템이다. 단지 API에 접근하기 위하여 인증과 권한이 필요할 때 OAuth2를 사용하여 인증을 받을 것이다. ( 물론 OAuth2 이외에도 다른 인증시스템이 있다. )
먼저 사전에 사용될 소스를 살펴보자.
API에서 사용될 도메인
@Data
@Entity
public class Member implements Serializable {
@Id
@GeneratedValue
Long id;
String name;
String username;
String remark;
public Member() {}
public Member(String name, String username, String remark) {
this.name = name;
this.username = username;
this.remark = remark;
}
}
Spring Data JPA 레포지토리
interface MemberRepository extends PagingAndSortingRepository<Member, Long> {}
현재 포스팅에서 주제는 OAuth2 서버 만드는 것이 목적이기 때문에 API 서버는 간단히 만들어 보려고 한다.
최근 스프링에서 진행되고 있는 프로젝트 중에 REST API 서버를 간단하게 만들어 주는 프로젝트가 있다.
두 번째 포스팅을 보면 추가된 의존성 중 Rest Repositories를 확인해 볼 수 있다.
보통 스프링 MVC에서는 API 형태를 만들 때에는 아래와 같은 형태로 API를 만든다.
기존 API 형태
@Controller
@RequestMapping("/member")
public class MemberController {
@Autowired
MemberService memberService;
@RequestMapping
public List<Member> all() {
return memberService.findAll();
}
@RequestMapping("/{id}")
public Member get(@PathVariable("id") Long id) {
return memberService.find(id);
}
...
}
하지만 이 포스팅은 심플한 API 서버를 만들 목적으로 Spring Data Rest 프로젝트를 사용해서 API 서버를 만들어 보려고 한다.
Spring Data Rest 형태
의존성은 앞서 추가했기 때문에 아래와 같이 위에서 추가한 MemberRepository에서 @RepositoryRestResource 어노테이션 설정만 하면 된다.
@RepositoryRestResource
public interface MemberRepository extends PagingAndSortingRepository<Member, Long> {}
MemberRepository는 알다시피 Spring Data JPA를 사용해서 만든 Repository 형태인데 따로 @Controller를 만들지 않고 @RepositoryRestResource 어노테이션만 붙여도 내부적으로 Rest API가 만들어진다.
어떤 요청을 만들어 주는지 살펴보겠다.
/{repository}/{id}/{property},methods=GET
/{repository}/{id}/{property}/{propertyId},methods=GET
/{repository}/{id}/{property},methods=DELETE
/{repository}/{id}/{property},methods=GET
/{repository}/{id}/{property},methods=PATCH || PUT || POST
/{repository}/{id}/{property}/{propertyId},methods=DELETE
/{repository},methods=OPTIONS
/{repository},methods=HEAD
/{repository},methods=GET
/{repository},methods=GET
/{repository},methods=POST
/{repository}/{id},methods=OPTIONS
/{repository}/{id},methods=HEAD
/{repository}/{id},methods=GET
/{repository}/{id},methods=PUT
/{repository}/{id},methods=PATCH
/{repository}/{id},methods=DELETE
/{repository}/search,methods=HEAD
/{repository}/search,methods=GET
/{repository}/search,methods=OPTIONS
/{repository}/search/{search},methods=GET
/{repository}/search/{search},methods=GET
/{repository}/search/{search},methods=OPTIONS
/{repository}/search/{search},methods=HEAD
어노테이션 설정 하나로 위와 같은 요청을 자동으로 만들어 준다.
위에서 {repository}가 의미하는 바는 어노테이션이 있는 레포지토리 인터페이스의 주 도메인 클래스명을 기준으로 해서 ( 앞글자는 소문자로 ) 복수형을 붙여 준다. 여기서는 도메인객체가 Member 이기 때문에 복수형이 자동으로 설정되어 members라고 들어간다.
물론 아래와 같은 형태로 직접 URI형태를 설정하여 사용할 수도 있다.
@RepositoryRestResource(path = "user") // "/user" URI로 변경된다.
interface MemberRepository extends PagingAndSortingRepository<Member, Long> {}
하지만 이 포스팅에는 최소한의 설정을 추구하려고 하기 때문에 될 수 있으면 기본설정값을 따라 갈것이다.
자세한 내용은 공식문서에서 확인하자. 여기에는 주소 자체를 커스터마이징 하는 방법이 잘 설명되어 있다.
스프링 데이터 Rest는 기본적인 형태가 조회뿐만 아니라 수정 및 삭제까지 모든 API들이 생성되는 형태이기 때문에 공식문서에서 잘 확인해서 제어를 잘하게 되면 실무에서도 활용이 가능할 것이다.
( 즉 위와 같은 형태는 예제에서만 사용하시라는 뜻! )
OAuth2 인증을 통해 보호하려고 하는 테스트 API를 단번에(?) 만들었다. 나중에 스프링 데이터 Rest 깊게 파서 사용할 일이 있으면 한 번 포스팅해보려고 한다.
위에서 생성된 API를 호출해보려고 하면 계정 정보를 요구하게 된다.
스프링 부트에서 스프링 시큐리티 설정하게 되면 기본적으로 서버의 모든 API를 디폴트 계정으로 접근 제한하기 때문이다.
참고로 기본 계정 정보는 아이디는 user, 패스워드는 랜덤 문자열이다.
(서버 시작 시에 패스워드가 랜덤으로 설정되며, 설정된 패스워드는 로그에서 확인 가능하다.)
하지만 원활한 테스트를 위해 계정을 설정해보겠다.
여기서 설정 정보는 "application.properties" 이 곳에 할 것이다.
# resources/application.properties
security.user.name=user
security.user.password=test
톰캣을 재시작한 후 OSX 또는 리눅스는 콘솔에서 curl, 윈도 계열이면 브라우저에서 주소를 호출해보자.
Basic 인증 형태이기 때문에 아래와 같이 호출할 것이다.
http://user:test@localhost:8080/members
또는 curl http://user:test@localhost:8080/members
자 다음 편에서 본격적인 OAuth2 서버를 만들어 보자!
다음 포스팅: 4. 간단한 OAuth2 서버 만들어 보기
이전 포스팅: 2. 본격적인 개발 하기전에
1. 스프링 부트와 OAuth2 (https://brunch.co.kr/@sbcoba/1 )
2. 본격적인 개발 하기전에 (https://brunch.co.kr/@sbcoba/2 )
3. API 서버 만들기 (https://brunch.co.kr/@sbcoba/3 )
4. 간단한 OAuth2 서버 만들어 보기 (https://brunch.co.kr/@sbcoba/4 )
5. OAuth2 서버를 커스터마이징 해보자(TokenStore 편) (https://brunch.co.kr/@sbcoba/5 )
6. API 서버와 OAuth2 서버를 분리 (https://brunch.co.kr/@sbcoba/6 )
7. JWT 방식으로 바꿔 보자 (https://brunch.co.kr/@sbcoba/7 )
8. OAuth2 서버를 커스터마이징 해보자(클라이언트 관리 편) (https://brunch.co.kr/@sbcoba/8 )
9. OAuth2 시스템에서 Scope를 이용한 API 권한 제어 (https://brunch.co.kr/@sbcoba/15 )
