Dropbox API logout then redirect - dropbox

In a 3rd party app, using dropbox API,
I'm trying to handle 2 or more Dropbox user accounts.
Which mean I try to logout a user (and keep its tokens valid) then login another.
to logout I use : https://www.dropbox.com/logout
However, when logging out, is it possible to redirect to my official redirect_uri ?
Something like: https://www.dropbox.com/logout?client_id=myclientid&redirect_uri=myredirecturi

No, the Dropbox API doesn't offer a way to do this. We'll consider it a feature request.

Related

How to use best use Google/Facebook signin using expo AuthSession to authenticate with a custom backend API

I am working on creating an mobile app using Expo (managed workflow). I have a backend server which this app will connect to. The backend server has its own authentication with username and password and all other endpoints are protected based on a token that you would receive by signing in to the API using a /authenticate endpoint.
Now, I would like to add a 'Sign in with Google' feature to my app. From the Expo's AuthSession documentations, it looks like somehow the app can authenticate with Google. I want to use this identity to authenticate with my backend API.
I created a /api/auth/google endpoint in my API that uses passport google-oauth, redirects user to google and get authorization code sent to /api/auth/google/callback. I then use the authorization code to access Google's people API, to get the email to validate the user and respond back with a access token for my API if the Google sign in was successful. This works fine when using in a browser.
I want to do something similar for the react-native app. When I use the Google example in Expo's AuthSession, it gives me back a access_token. I have no idea how it gets an access_token because the app does not know my client secret. But still, I don't know how to use it to login to my API and get my API's token.
I have thought about using AuthSession to directly open my API's /api/auth/google, so it would redirect correctly and my backend can then send my API's token to the app. The problem with this is, when someone clicks on the 'Sign in with Google' button in the app, apple will tell you 'App name wants to use myapi.com to sign in' or something along those lines instead of Google.com. Additionally when I add more sign in options like Sign in with Facebook and Sign in with Something else, the user's phone will always say that the app wants to use myapi.com to sign in and then in turn be redirected to Google/Facebook or something else. I am not sure if this is allowed and would count as misleading the user and get rejected form the app store. I tried logging into some of the apps on my phone and clicking on 'Sign in with Google' tells the app is trying to sign in with Google.com and 'Sign in with Facebook' tells that the app is trying to sign in with Facebook.com correctly. But then I also know that the app eventually authenticates with its own API somehow. I don't know what is the right way to do that.
Can someone help? Thanks.

Okta re enter password after logging in for a particular action

I'm using okta to sign-in to my react based web application. There is an edit action within the app that requires the user to re-enter his password. I've checked the docs and couldn't find anything similar. The closest I got to was the 're-authenticate' user part. However, that's only based on time. I want to achieve similar functionality based on an event(say, button click). Can I do this using refresh tokens? (I'm not clear about the whole idea of refresh token). Is there a workaround or a specific okta API that allows me to do this?
I have contacted Okta support and they advised me to use the Okta MFA factors(OTP to email/phone, Google Auth etc.) and not to prompt the user to enter a password.
MFA Factors API: https://developer.okta.com/docs/reference/api/factors/

is there any way to "logout with all devices" from dropbox API v2

I am using Dropbox API v2. User of my app wants to logout from Dropbox with all his devices. I think this is equivalent to revoke all access tokens for my app.
I know how to revoke a known access token (and my app provides a logout which does this).
I also know that the user can unlink my app from his dropbox on the dropbox website (but this is a bit cumbersome).
For convenience, I would like to add a feature allowing him to do this from my app.
Another reason is, that processing of the callback-URL may fail. Then the generated access token remains valid, even if it is never used.
As Dropbox access tokens never expire, users might feel bad if there are unknown or unused access tokens flying around.
No, the Dropbox API doesn't offer a way to programmatically unlink/revoke all access tokens for an app. We'll consider this a feature request.
I used to redirect to logout page, which invalidate the token as well as "ask for permissions" for app on the next login ... it is not aesthetic, but worked.
if (this.isAuth()) {
this.authToken = '';
window.open('https://www.dropbox.com/logout', '_blank');
}

Multiple ember apps with one login app

I have multiple ember apps, but just one of them has the login page. I want to authenticate all of them with this unique page. How can I redirect other apps to an external login page using ember-simple-auth and redirect to the corresponding app after the authentication?
You need to write custom authenticator. In it's authenticate method I suggest to not redirect, but open a child window with login page. And that login page should be able to communicate with your ember app in some way (window.postMessage for example) in order to give your app auth token. Authenticator must wait until it receive answer (promise and timer will help with waiting). I used such method with google's oauth in node-webkit application (my authenticator opens google's oauth page where user prompted to give my app an access). I don't want to share a code because its too big, complex and have code specific to nw.js but I hope my answer will help. I used code of oauth2 authenticator to develop my own, it helped me a lot.

The use of FacebookAuthProvider in apps

I've been working with ServiceStack for quite some time now and i love it. But there is one thing i can't figure out.
How are app's (ios, android etc.) that are using my servicestack endpoints, suppose to use the facebook endpoint "/auth/facebook"?
When using this url "/auth/facebook" from the browser it works fine, but the response is html, and not an AuthResponse og something serializable.
Is this endpoint only to be used from websites with servicestack in the same solution?
The way that stuff works is by redirecting the user to Facebook with an API key that matches your app. The user then tells Facebook that your app is ok, and Facebook redirects them back. This can only be done via a browser. You really have two options to work around this:
Make the user authenticate with Facebook using a website and then authenticate your user with credentials from the app.
Use the built in iOS Facebook stuff and send the resulting auth tokens to an endpoint on your app, where you can save them for later use.
Edit, a bit more clarification:
Option 1
User Goes to your website
User Clicks on your Auth With Facebook button
User is sent your your Facebook endpoint set up in Service Stack
User is redirected by Service Stack to Facebook
User is redirected back to Service Stack from Facebook, with a token in the url
You save the token in your database and tell the user they can now user your app with Facebook.
Option 1.5
The same as Option 1 but instead of making the user go through their browser you create a UIWebView control and point it to your Facebook Auth endpoint. Then you listen for a response from your site that says the user is authenticated. I'm not a objective c, so I can't really get more detailed on how to do that.
Option 2
Use the iOS Facebook API and handle authentication as seen here.
POST the credentials to Service Stack via a Custom Endpoint
Save credentials in the db, and use them in the future to make calls on behalf of the user.
Facebook Login requires a browser of some sort, because Facebook's cookies must be passed along with a request to authorize your website. That is how Facebook knows which of it's users wants to authorize your site, and that they are the ones making the request.