I'm currently testing SWIA implementations, and found some interesting behavior related to scope in the authorization flow.
Situation that I'm facing right now is:
User signs in with his/her Apple Id through the mobile app's or website's SWIA feature for the vert first time without email scope.
User will be granted JWT without email claim as expected.
Later, we changed to add email scope for the authorization process.
User (from #1) signs in again, and goes through SWIA with email scope
User will be granted JWT without email claim
Unless otherwise user manually de-authorize the app from their Apple ID portal (or in the mobile app), updated scope will not be reflected
It also happens in the opposite way (i.e. having email scope for the very first request, and then later remove email scope. This will still grant JWT with email claim)
Is this something expected from Apple's OIDC server? or am I doing something wrong? I've tested it with both native iOS SWIA and on the web client as well, and both produce the same result.
Not quite sure if this is as per OIDC specification.
Any insight or help would be greatly appreciated.
I know its a late reply, Sign in with Apple does not provide incremental changes to the user scopes. If some user authorized with initial scope won't get until he revoke our application as described here https://support.apple.com/en-us/HT210426.That mean the newly added scope, only affects newly authorized users, and would include the email claim in their identity token (and in the initial user body of the authorization response).
Additionally the above steps don't show the option to revoke the app until at least one of the app login happens and the app should be in production not sandbox or testing.
apps not showing as there is no app requested for email/name
it will appear if login success from production app
Related
I'm writing an offline application that uses the Dropbox API. When a user comes to the application, I'm using the https://api.dropbox.com/oauth2/token (docs) to get a refresh_token, which I store for later use.
I am calling the same endpoint every time the user logs in (unless I've already got the user's data in a cookie). I'm not sure that this is the best way to go about it: I at least need to get the user's account_id, so that I can look up their refresh_token in the database if I already have it. But every time I call https://api.dropbox.com/oauth2/token, the user is redirected to the Dropbox app authorization interface, as if they've never approved the app before.
So I would either like to know how to stop Dropbox from forcing the user to re-authorize an app every time. Or, if that is just how https://api.dropbox.com/oauth2/token is supposed to work, I'd instead like to be able to get their account_id somehow when they visit my page.
(In case it's relevant, the app is still in development mode at this point.)
The https://api.dropbox.com/oauth2/token endpoint is an OAuth endpoint that the app can call to get an access token/refresh token. Being an API endpoint, it does not itself redirect the user to the Dropbox app authorization page.
The Dropbox app authorization page is at https://www.dropbox.com/oauth2/authorize (documented here), and the app decides if/when to direct the user there to authorize the app.
You generally only need to send the user through the app authorization flow (sending them to https://www.dropbox.com/oauth2/authorize and then calling https://api.dropbox.com/oauth2/token) once per user for an "offline" application. Once you do so, you should store the resulting refresh token for that user. You'll typically store the refresh token for that user tied to their user account in your own app.
Exactly how you manage the user accounts in your own app will depend on how it's built, but, as it sounds like this is a web app, typically you would use the user's browser cookies to identify the user when they return to your page so that you can look them up in your database and retrieve their details, such as their corresponding refresh token. (Or, if they're not already signed in to your web app, you would have them do so first.)
Greg's answer is very helpful, and very politely addresses my misunderstanding of the auth flow. (I was revisiting old code I'd written years previously—obviously I should have documented it better than I had!)
In the end I believe that Dropbox was forcing me to reauthorize because my application was in development mode, and had a small user base. When I used the identical code in an app set to production mode, it stopped forcing me to reauthorize. So the “problem” is really a Dropbox security feature, and the solution was just to use production mode.
If in Azure portal, I set Enterprise applications > Properties > User assignment required? to No, then authentication works as expected. However, if I turned it on, users get error Application needs permission to access resources in your organization that only an admin can grant. I understand that I need to add an API permission to my app, but what is it?
Interestingly, if a user has signed in into the app before, then they are not affected when turning the option on. Only users who have never use it are affected
Edit: To clarify, I already have App roles created. Users without app roles can't sign in, as expected. Users WITH app roles who sign in for the first time after the the option turned to Yes get the above error
Finally, I reproduce your issue with the request URL below, the scope also could be another one, e.g. https://storage.azure.com/.default, which has been added in the API permissions of the AD App.
https://login.microsoftonline.com/<tenant0id>/oauth2/v2.0/authorize?
client_id=xxxxxxx
&response_type=code
&redirect_uri=http://localhost
&response_mode=query
&scope=https://management.azure.com/.default
&state=12345
If the User assignment required is set to Yes, I notice it will not promote the user to consent the permissions. (e.g. user_impersonation in the Azure Service Management API.)
To fix the issue, we need the admin consent to the App, just navigate to the API permissions, click the Grant the admin consent for xxx button, then it will work fine.
I will explain the scenarios here
1) When user click on link facebook button facebook permission dialog is bypassed and returns back directly on redirect uri(http://localhost:3000/ in my case) with code and state.
2) I am successfully able to exchange the code return above with access token.
3) I used facebooks access token debugger to analyze the token above and shows be proper scopes i need.
4) After this i fetch ad_accounts id, page token and page ids using this token.
5) when i use this token to create campaign for ads i get the following error.
FacebookAds::ClientError (Invalid parameter: Terms of Service Not Accepted (fbtrace_id: Ch/RdwGB+D3))
I use ruby facebook-business-sdk.
My app is in development mode and not live yet.
I can see both facebook login and marketing api green live in my app dashboard.
It makes sense to me that i am getting "Terms not accepted error" as user is never prompted to permissions dialog to permit my app for token.
I also observed that if add scope params to facebook login uri, the user is prompted to permission dialog.
I must be missing some configuration here, i have not yet submitted my app for review.
Any help/clue is appreciated.
I am unable to revoke application access by a user via either a password reset or by explicitly clearing app keys in user management. The latter method gives a reply indicating that access has been revoked, but when the user hits the tool, they are not re-prompted to approve access to their information.
There are number of possibilities here:
It's possible that there is latency between the declared revocation of keys and the cleanup task that goes through the database and actually cleans them up; I believe that at one point, such a latency existed, was identified, and fixed through service packs and subsequent releases. Accordingly, you may address this issue by ensuring that your back-end service is up-to-date with its available service packs.
It's possible that what's being revoked is the keys, and the necessity to authenticate to rebuild keys, but not the confirmation step that would appear to the user asking for access permission (assuming the user once authenticated, and checked the "don't prompt me to ask for permission again") dialog.
Can you confirm if the request for user tokens by the client application actually does get back tokens? Or is it just that the authentication step happens with no notice of client confirmation to access?
Note that the re-authentication might appear to happen silently; if the client application's request for user tokens happens through a user's browser context where the back-end service can determine that the user is already logged in to the LMS, then the request for tokens could succeed automatically:
The user is assumed to have already authenticated in order to have an active web session, so there's no need to re-gather a username/password (or whatever user auth step the LMS uses) to re-confirm identity.
The user may already have confirmed access for the application and dismissed the confirmation step with "don't ask me again". If the user has confirmed access with "don't ask me again" this choice will get remembered, even if the user tokens get expired due to password change or access revocation by an admin.
If you explicitly log a user out of their LMS session, and then test the client app, this should indicate to you visibly whether the re-authentication step is actually taking place (the user's browser will then get directed to the login process for the back-end service).
Note that, although a user password change or access revocation by an admin can remove the recorded user Id/Key pair associated with an application, it does not remove the record of the confirmation form having been dismissed with "don't ask again". Currently our system does not expose a way to reset that confirmation state.
If after considering these points you feel you still have an issue, I would encourage you to open a support incident through your organization's approved support contact, or your account or partner manager. Desire2Learn takes security related reports quite seriously, and if you've uncovered an issue that hasn't yet been addressed, I would encourage you to report it as a defect.
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.