애플리케이션이 사용자를 대신하여 데이터에 액세스해야 하는 경우 이를 3-legged OAuth 흐름이라고 합니다. 3-legged OAuth 흐름에서 애플리케이션은 계정에 로그인하여 인증을 완료하는 최종 사용자로부터 사용자 인증 정보를 가져옵니다. 그러면 애플리케이션이 최종 사용자의 사용자 인증 정보를 사용하여 사용자를 대신하여 Cloud Storage 리소스에 액세스합니다. 다음은 이 접근 방식을 사용할 수 있는 시나리오의 예시입니다.
최종 사용자를 위한 여러 인증 옵션을 지원하도록 애플리케이션을 설계하는 경우 이메일 및 비밀번호 인증은 물론 Google, Facebook, Twitter, GitHub 등의 ID 공급업체를 이용하는 제휴 로그인을 지원하는 Firebase 인증을 사용합니다. 서로 다른 사용 사례에 맞게 인증 시스템을 설정하는 방법에 대한 자세한 내용은 Firebase 인증은 어디에서 시작하나요?를 참조하세요.
애플리케이션에 사용자를 대신하여 최종 사용자로부터 데이터에 액세스할 수 있는 액세스 토큰이 부여된 경우, 해당 액세스 토큰에는 토큰을 부여한 사용자에게만 허용된 권한이 있습니다. 예를 들어 jane@example.com이 example-bucket에 대한 read-only 액세스 권한을 갖는 경우, Jane이 read-write 액세스 권한을 부여한 애플리케이션은 Jane을 대신해서 example-bucket에 쓸 수 없습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(UTC)"],[],[],null,["# Accessing data on a user's behalf\n\nWhen your application needs to access data on a user's behalf, this is called a\nthree-legged OAuth flow. In a three-legged OAuth flow, your application obtains\ncredentials from an end user, who signs into their account to complete\nauthentication. Your application then uses the end user's credentials to\naccess Cloud Storage resources on the user's behalf. Here are examples\nof scenarios where this approach can be used:\n\n- Web server applications\n- Installed and desktop applications\n- Mobile applications\n- Client-side JavaScript\n- Applications on limited-input devices\n\nFor more information on these scenarios, see [OAuth 2.0 scenarios](https://developers.google.com/identity/protocols/OAuth2#scenarios).\n\nFor other scenarios, you might want to use [service account credentials](/iam/docs/service-account-overview#credentials).\n\nIf you are designing an application to support multiple authentication options\nfor end users, then use [Firebase Authentication](https://firebase.google.com/docs/auth/), which supports\nemail and password authentication as well as federated sign in with identity\nproviders such as Google, Facebook, Twitter, and GitHub. See\n[Where do I start with Firebase Authentication](https://firebase.google.com/docs/auth/where-to-start)\nfor details on how to set up authentication systems for different use cases.\n\nWhen an application is granted an access token by an end user to access data on\nthe user's behalf, that access token only has the permissions available to the\nuser who grants the token. For example, if jane@example.com has `read-only`\naccess to `example-bucket`, an application which Jane has granted `read-write`\naccess to will be unable to write to `example-bucket` on her behalf.\n\nWhat's next\n-----------\n\n- Learn more about [authentication in Cloud Storage](/storage/docs/authentication)."]]
