We're attempting to figure out what role is necessary for a user to have to generate an APNs certificate through the Apple Developer Portal. It appears that we currently have Developer role, and that this isn't enough (the only certificates that appear are for signing). We have another account that has an Admin role which does have access, but we want to be certain that an Admin role is required, as we'd prefer to request least permissions.
Setting up APNS with either TLS or autentication tokens require either the Account Holder or Admin role.
Can you add or enable the Account Holder role on your Developer account?
Here are a couple of links about APNS authentication types:
Communicate with APNs using authentication tokens
Communicate with APNs using a TLS certificate
Here is some more info about roles:
Program Roles
Hope this helps! Getting APNS set up is always a chore.
Related
The use case is quiet simple, I want to read and write to calendars on a daemon (backend workflow) from personal Microsoft account or azure AD account.
Then I registered an Enterprise application in Azure Active Directory admin center with:
the account type « Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) ».
permissions on read write on calendars + read on user
a generated client secret
a redirect uri
For all accounts from the same Azure Active Directory, the authentication with the client secret and the impersonation of the targeted email works well.
But for personal Microsoft accounts it is not. If I understood correctly I need to use the client credentials flow to grant the user. Then the user need to go on the admin consent url as explained: https://login.microsoftonline.com/common/adminconsent?client_id=<client_id>&state=12345&redirect_uri=<redirect_uri>.
But when logging in with a personal account it results in a redirection to the specified redirect uri with the error:
AADSTS500200: User account '{EmailHidden}' is a personal Microsoft account.
Personal Microsoft accounts are not supported for this application unless explicitly invited to an organization.
Try signing out and signing back in with an organizational account.
Research
I tried some solution of the error AADSTS500200 with this article: https://github.com/MicrosoftDocs/SupportArticles-docs/blob/main/support/azure/active-directory/error-code-AADSTS50020-user-account-identity-provider-does-not-exist.md (note that the error number is missing a last zero). But I still receive the same error or an other error Needs admin approval when the personal account is invited.
Needs admin approval (french only)
Question
Is it possible to read data on personal Microsoft account ? How to achieve this ? Is there any other way ?
It is not possible to use Microsoft personal accounts with the client credentials flow.
The solution is to use the authorization-code flow and use the scope offline_access during the authorization request and the token request. So that the refresh_token that can be used to regenerate new refresh_tokens.
When one account per email address is enabled for Firebase Authentication in a Firebase project there seems to be some additional rules that apply to the authentication process. The different providers seem to be split into two categories, trusted and untrusted providers. If at any point a user signs in through a trusted provider all untrusted providers the user has signed in with before are removed from the account. Additionally a user will never be allowed to sign in with an untrusted provider ever again. Whether a provider is trusted or untrusted seems depend on whether a new account created with a provider validates that account exclusively through sending a verification email to the address the new account was created with.
I cannot seem to find a comprehensive list as to which providers are trusted and untrusted. Through implementing the solutions into my app I have found the following:
TRUSTED PROVIDERS:
Apple
Google
Microsoft (If the email the account was created with is
a #outlook.com or #hotmail.com)
UNTRUSTED PROVIDERS:
Facebook
Microsoft (If the email the account was created with is not a #outlook.com or #hotmail.com)
Is this understanding correct? Where can I find a breakdown of the rest of the providers? My app is built in Unity so I would be limited only to the providers Firebase supports in Unity. Why is Microsoft both a trusted and untrusted provider in different circumstances? I could really use some help here.
My app is for iOS and Android. I wanted to exclusively use Apple and Google sign in but Apple sign in is unavailable to users on iOS < 13. These iOS devices seem to represent about a 6th of all devices in western nations. I tried to implement Google and Microsoft sign in to get good coverage of these users but then I ran into the complication with Microsoft sign in being both trusted and untrusted. I don't want to over complicate my app with manual account merging, but I don't know what other providers are wholly trusted. What is the best solution here to keep things simple stupid?
Trusted providers:
Google (provided it was issued by Google, eg. #gmail.com)
Yahoo (provided it was issued by Yahoo, eg. #yahoo.com)
Microsoft (provided it was issued by Microsoft, eg. #outlook.com)
Apple (always verified. Apple's selling point is that accounts are verified and multi-factor authenticated).
Email link authentication.
Untrusted providers use emails that were not issued by the provider:
Facebook
Twitter
GitHub
Google, Yahoo, Microsoft, etc provided they were not issued by that IdP.
Email / Password without email verification
Firebase Auth plays it safe and does not consider certain providers verified, because in some cases, email is verified once but is not continuously verified (in some cases, IdPs allow you to change the email after verification without requiring re-verification).
The best way to explain the sensitivity of an unverified account is the following:
1. Attacker signs up with unverified provider (password) using email victim#example.com which they do not own
2. Email owner signs up with victim#example.com using verified provider Google.
If the account is not reset and the password unlinked, then the attacker maintains access to that account which they do not own. To solve this issue, the user has to verify the email (by sending email verification) before step 2. By doing so, sign in with Google will automatically merge accounts and keep the password.
This is why in some cases, you will get an error:
Sign up with unverified provider using email user#example.com
sign in with another unverified provider of the same email
Error thrown requiring linking after verifying ownership of first account.
User expected to sign in to account from step 1.
User can now link credential of account from step 2.
Here is a summary of the behavior in various cases:
existing unverified provider, sign in with another unverified provider of same email -> error requiring linking thrown. (eg. Facebook followed by GitHub)
existing verified provider, sign in with another unverified provider of same email -> error requiring linking thrown. (eg. Google followed by Facebook)
existing unverified provider, sign in with verified provider of same email -> verified provider overwrites unverified provider. (eg. Facebook followed by Google)
existing verified provider, sign in with another verified provider of same email -> Both providers linked without any error. (eg. Apple followed by Google)
If you do not agree with Firebase Auth and want to consider Facebook as a verified provider, you can always set the email as verified after Facebook sign-in by using the Admin SDK.
Hopefully this helps clarify this behavior.
I've recently learned of the new APNS Authentication Key mechanism which is set to replace the functionality of the existing system of APNS certificates.
From my understanding this key supersedes all existing certificates, and can authenticate requests for all my apps.
I am confused about the transition though. Does this key only work for apps that are newly built/provisioned/released? My Firebase console invites me to upload my new APNS Authentication Key, but upon doing so, warns that my existing certificates which are being used in production will be removed. Does this mean my existing users will stop receiving push notifications?
IMHO, transitioning from certificate-based to authentication token-based only affects how your application server communicates with the APNS provider, thus existing users of your application will not be affected.
I have some MDM solution that we've developed through which we want to support managing iOS devices. Even though we'd already been able to successfully enrol and manage iOS devices via the same, I am trying to figure out a way to secure all web service invocations with OAuth, which take place between the native app running on iOS devices, connecting to the Enrolment and other APIs deployed as part of the MDM solution. Apparently, we've got limited control over modifying the native app to embed OAuth access tokens in the form of HTTP headers or some other means to be able to send those access tokens across to the MDM APIs, as the app logic cannot be modified. Do we have any configuration in the Enterprise App that runs on iOS devices to enable OAuth (or any other form of authentication) or some other means, which I can effectively use to get my requirement implemented?
iOS enrollment flow associate with a challenge token in the SCEP payload (mentioned as Challenge). Once you do the authentication from MDM server side there needs to be a unique token generated based on your user identity and embed that in this SCEP payload. For subsequent enrollment calls this token is passed and once the enrollment success this can be fetched and validate the user. Ideally this is just a way to link the device to a specific user which could be a temporary token generated at your MDM server end which link to a user identity or something related. To follow that you could apply OAuth password grant type and get the token once the authentication happens. Then this OAuth token can be then set as this challenge token for future use. But unlike in other OAuth communications iOS will not send this token in header as the bearer rather this will be embedded in the xml payload with proper encryption and signing in place.
Further iOS support protocol extension to validate users with open directory service using an auth token. This will by default have the ability to communicate back and forth using the checkin endpoint.
Short version: Can my application authenticate itself with OAuth 2.0 without using a service account?
Long version: The issue I'm having with service accounts is that they can't be granted the same permissions as the original account that created them. Specifically, my company doesn't grant external accounts write permissions for security reasons. A service account is technically an application specific account, outside of the domain of the account that created it, and has more restricted access than an end-user account.
Is it possible for an application to authenticate itself as a user account?
Service account is allowed to impersonate a user to get an access token.
See https://developers.google.com/accounts/docs/OAuth2ServiceAccount#formingclaimset Additional claims section.
https://code.google.com/p/google-apps-manager/wiki/GAM3OAuthServiceAccountSetup has description for how to configure it.