는 AccountManager다음과 같은 이유로 좋은 :

• 첫 번째는 단일 계정 유형으로 앱 기능에 대한 액세스 수준이 다른 여러 계정 이름을 저장하는 것입니다. 예를 들어, 비디오 스트리밍 앱에서 하나는 두 개의 계정 이름을 가질 수 있습니다. 하나는 제한된 수의 비디오에 대한 데모 액세스 권한이 있고 다른 하나는 모든 비디오에 대한 전체 월 액세스 권한이 있습니다. Accounts그러나이 멋진 외관을 요구하지 않고도 앱에서 쉽게 관리 할 수 ​​있기 때문에을 사용하는 주된 이유는 아닙니다 Accounts.
• 사용의 또 다른 장점은 Accounts인증이 백그라운드에서 수행되고 사용자에게 특정 조건에서만 비밀번호를 요청하기 때문에 사용자가 권한 부여 된 기능을 요청할 때마다 사용자 이름 및 비밀번호로 기존 권한을 제거하는 것입니다. 나는 나중에 그것을 얻을 것이다.
• Accounts안드로이드에서이 기능을 사용하면 자신의 계정 유형을 정의 할 필요가 없습니다. 인증을 위해 Google 계정을 사용하여 앱을 방문했을 수 있습니다. 그러면 새 계정을 만들고 사용자의 자격 증명을 기억해야하는 번거 로움이 줄어 듭니다.
• Accounts 설정 → 계정을 통해 독립적으로 추가 할 수 있습니다
• 를 사용하여 크로스 플랫폼 사용자 권한을 쉽게 관리 할 수 ​​있습니다 Accounts. 예를 들어, 클라이언트는 반복적 인 로그인없이 Android 기기와 PC에서 동시에 보호 된 자료에 액세스 할 수 있습니다.
• 보안 관점에서 서버에 대한 모든 요청에서 동일한 비밀번호를 사용하면 비보안 연결에서 도청이 가능합니다. 비밀번호 도용을 방지하기 위해 비밀번호 암호화로는 충분하지 않습니다.
• 마지막으로, AccountsAndroid에서이 기능 을 사용하는 중요한 이유 Accounts는 클라이언트 (사용자)의 자격 증명을 손상시키지 않고 인증 자 및 리소스 소유자 에 의존하는 비즈니스에 관련된 두 당사자를 분리하는 것 입니다. 용어는 다소 모호해 보일 수 있지만 다음 단락을 읽을 때까지 포기하지 마십시오… ?

비디오 스트리밍 앱의 예를 통해 후자를 자세히 설명하겠습니다. 회사 A는 특정 회원에게 프리미엄 스트리밍 서비스를 제공하기 위해 회사 B와 계약 한 비디오 스트리밍 비즈니스의 소유자입니다. 회사 B는 사용자를 인식하기 위해 사용자 이름과 비밀번호 방법을 사용합니다. 회사 A가 B의 프리미엄 회원을 인식 할 수있는 한 가지 방법은 B에서 해당 회원의 목록을 가져오고 유사한 사용자 이름 / 암호 일치 메커니즘을 이용하는 것입니다. 이런 식으로 인증 자와 리소스 소유자는 동일합니다 (회사 A). 두 번째 비밀번호를 기억해야하는 사용자의 의무 이외에, A의 서비스를 사용하기 위해 회사 B의 프로파일과 동일한 비밀번호를 설정했을 가능성이 높습니다. 이는 바람직하지 않습니다.

위의 단점을 해결하기 위해 OAuth가 도입되었습니다. 승인의 공개 표준 인 위의 예에서 OAuth는 적격 사용자 (타사)에게 액세스 토큰이라는 일부 토큰을 발행하고 회사 A (자원 소유자)에게 토큰. 따라서 토큰이 없다는 것은 자격이 없음을 의미합니다.

나는 이것에 대해 더 자세히 설명하고 여기AccountManager 내 웹 사이트 에서 더 자세히 설명 했다.

---

답변