Is it Possible to somehow include Device_ID and information about the device in Bearer token Claims, or is this only Possible through a BYOD MDM subscription?
I have read about this for some while now and haven't found anything to make this happen, though there are hints around pointing at for example the refresh_token containing that information (Which i haven't found a way to check just yet).
Device_ID in refresh_token
Also Reading about MDM (Mobile Device Management) this is possible it seems.
About BYOD and MDM Under the topics:
"Terms of Use protocol semantics" and "Management protocol with Azure AD"
i have also asked about "custom" claims before (with no luck, unfortunately) and was asked to repost a more specific question.
Previous post
Related
What information is used by APNS to generate device tokens and identify that it's unique to the device and app?
I have gone through apple documentation but it only tells that the token is unique to device and app , but how the token gets generated the process is not diclosed.
It's an opaque token. By design, you're not going to be able to reverse engineer how APNS tokens are generated and make your own.
If it helps, you might think of an APNS token as a hash of a bunch of things, some of which you can't see or control.
I'm building an OIDC/OAuth server that will provide an SDK much like sign in with Google to be an IDP for mobile apps. We are wondering the risks of deviating from the protocol to simplify the flow.
The flow would be like this:
OIDC Server is setup for company A.
User opens app from company B, using company A OIDC SDK, and enters email
Pin challenge sent to email
Pin entered in app, screen shows consent prompt
On ok, app gets ID + Auth token for user
The token accessible to the app is only scoped to a limited set of resources accessible to the app and can be revoked by the user at any time.
This cuts out a few steps from the normal PKCE+Auth code flow, and I’m having a hard time articulating why this may be worse for security (besides not following a widely accepted standard).
Standards around security are created so that common attack vectors can be more easily mitigated. If you don't follow the standard you will have to make sure yourself that you're meeting security requirements of your product/company.
It's hard to tell from that simple description whether your app will be vulnerable or not. E.g. in point 4 - how do you make sure that the app which sends the OK to consent is the one which asked for the consent in the first place? How do you make sure that the auth token is delivered to the appropriate app? What will be the TTL of such a token? How will you refresh it? What is your plan for a situation when the token gets stolen or intercepted, etc. These are all things which you will have covered if you follow OIDC or OAuth standards and their security recommendations. When you start inventing new ways to guard yourself from those threats, you might end up creating something similar to the standards anyway.
Also, if you implement standard flows, it will be easier for you to change your own OAuth Server to a product available on the market, should that become a necesity.
There is a standardised OAuth 2.0 extension that somewhat resembles your approach, defined in RFC 8628 https://datatracker.ietf.org/doc/html/rfc8628 "OAuth 2.0 Device Authorization Grant".
A few remarks about your flow:
it seems to imply that the ability to read e-mail equals user authentication i.e. the e-mail provider is the authentication provider; that may not be applicable in general
the spec warns that this approach should not be used to replace vanilla browser-based SSO on mobile devices that do have a browser mostly because of loss of flexibility and it results in a more cumbersome user experience
I don't think there are immediate or more security concern than the ones mentioned in RFC 8628 (https://datatracker.ietf.org/doc/html/rfc8628#section-5), but as mentioned before, you'd be on your own to find support in SDKs, apps and OPs when not following the standard
I'm just trying to expand my discord bot capabilities, so I've decided to get started on making an OAuth2 application for my bot. Upon looking at the Developer Portal, I've noticed that there are various OAuth2 URLs that I can use for my application. So I was wondering what the differences are between links used. I know the three represent the base authorization, token, and token revocation, but what does that mean exactly? I don't have much experience in this field, so try explaining it to me like I'm five.
tl;dr: What do the three OAuth2 URLs each represent? What's the difference for each, specifically the meanings behind the "base authentication", "token", and "token revocation"?
The documentation explains it.
from the docs:
The authorization code grant is what most developers will recognize as "standard OAuth2" and involves retrieving an access code and exchanging it for a user's access token. It allows the authorization server to act as an intermediary between the client and the resource owner, so the resource owner's credentials are never shared directly with the client.
The https://discord.com/api/oauth2/authorize link is for authorization of your application by a user/resource owner. which gives you a code. you use the code with the second link to https://discord.com/api/oauth2/token to get the token that you will to access content of the user/resource owner
I saw the description
You may verify the refresh token up to once a day to confirm that the user’s Apple ID on that device is still in good standing with Apple’s servers.
in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user .
I have two question about the description:
Why should we verify the refresh token instead of access token to confirm the user's Apple ID is still in good standing with Apple's server?
The doc said refresh token can only verify once a day. But i can verify refresh token multiple times in practice. Is there some conflict between documentation and implementation?
Update on 10/17/2019：
For apps running on other systems, use the periodic successful verification of the refresh token to determine the lifetime of the user session.
I also saw the description above in in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user . I think periodic is also conflict with once a day.
Right now, I store the access_token and set custom expires time for follow verify request. And get notification from iOS client(getCridentialState) to delete access_token.
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.