I'm implementing Twitter auth into a React Native app, which uses bunch of Firebase features, including Firebase Auth.
As far as I'm concerned, neither Firebase Auth SDK nor FirebaseUI, which manages to carry whole authentication flow on web, hasn't been bridged to React Native yet(?). So I have to carry the first part of auth flow on my own. By the first part I mean get provider Access Token and turn it into credentials, which can then be passed to Firebase Auth signInWithCredential.
This is what I've done for Facebook using Facebook SDK.
const fbAuth = async () => {
const result = await LoginManager.logInWithReadPermissions(facebookPermissions);
if (result.isCancelled)
throw error;
const { accessToken } = await AccessToken.getCurrentAccessToken();
const facebookCredential = firebaseAuth.FacebookAuthProvider.credential(accessToken.toString());
await firebaseAuth().signInWithCredential(facebookCredential);
}
Firebase Auth than carries the rest for me and I'm successfully done.
I would like to do the same thing for Twitter. Unfortunately there is no Twitter SDK, that would allow me to achieve this in couple of steps like Facebook SDK.
It seems I will have to do the whole OAuth dance for Access Token on my own.
I would like get some opinions what are the best practices to approach this situation.
Twitter Use-case
According to Twitter docs I have to perform direct calls to the API. The calls obviously contain secrets, which cannot be stored in a client app and I don't really fancy creating an Auth server (as I'm not sure about how would the flow work). I would like to keep this as much client-level as possible.
Would love to hear opinions on how to achieve this and what would the flow look like.
Related
I'm trying to get my head around setting up an OpenID Connect server for SSO authentication. I think my basic setup/requirements are pretty standard, but I'm having a little difficulty putting it all together.
The broad setup is a single page application, a web API, and an identity server. The SPA is served from the same domain name as the web API and the ID server is on a different domain, so I might have several SPA/Web API combinations, but of course every case is the same setup (single host with static content and an API). At the moment I'm working with IdentityServer4 to create the identity server; I'm flexible to trying other providers if there's some kind of problem with that one, but so far so good.
My login requirements are also pretty standard I think; I want to have short-lived access tokens and I also want to use refresh tokens to implement a sliding expiration so users don't have to be redirected off of my SPA until they've been inactive for "a while" (however I end up defining that).
After a bit of research, I think what I want is to use the authorization code flow. So generally, the way I thought this would work is:
A user visits the application host (that serves the web API and SPA); the static SPA is served
The SPA loads and determines that there is no access token in local storage. The SPA kicks off the login process by producing a random identifier and storing it in session storage, then navigates the browser to the ID server host
The user authenticates with the ID server host
The ID server hosts redirects to the client and includes in the redirect the random identifier the SPA originally generated along with an authorization code
Upon loading and detecting that it got an access code, the SPA checks session storage for the identifier stored in step 2. Finding it, the SPA calls the web API to exchange the authorization code for an access token
The web API uses a back channel with the ID server to produce an access token and refresh token
The web API stores the refresh token and access token then issues the access token to the client
In all future requests, the client uses the access token with the Web API. When the SPA determines that the access token it has is expired or about to expire, it request a refresh somehow (I'm going to hand-wave the refresh a bit for now)
So I went through the tutorial on the IdentityServer4 site, and to my surprise I ended up in a bit of a different state. It took me a while to work through it; the step I'm talking about if anyone wants to follow along is "Adding a JavaScript Client", but I'd be willing to be the result is common among people implementing OpenID Connect. The resulting flow differed from what I expected starting with step 5; instead of the SPA calling the web API with an authorization code and requesting an access token, the SPA uses CORS and makes a cross-domain request back to the ID server to request the access token. The tutorial didn't really cover refresh tokens all that much (there's other parts of the docs that do, but only briefly), but I think the implication is that if I wanted to use refresh tokens they'd be issued to the client and it would use local storage to store them; then for future refreshes it'd also do a cross-domain request back to the ID server. As a side note, another bit of surprise was that the tutorial has you use PKCE, which on research seems to be unnecessary for a web application; it's somewhat important as including a SHA-2 implementation client-side increases the size of my application by a fair bit.
I believe it is a bad practice to issue a refresh token to a web client and ask it to store it; I'm somewhat vague on the specific vulnerabilities that opens up, but the general idea is that if someone subverts your client somehow, a refresh token is considerably more powerful than a short-lived access token.
So, getting my head around this, I believe the way I originally though this would work was that the web API is the "Relying party" in OAuth 2 parlance, and the tutorial set it up so that the client is the "Relying party". It makes me think that if I want to get a sliding expiration, I have to go past where the tutorial went and move the functionality for token exchange from the client into the web API like I had originally envisioned. It would end up looking a bit like the web API functionally being a proxy for the SPA to exchange the authorization code for an access token.
Ultimately, my question is: am I getting this right? It looks like there are really two different models for implementing OpenID Connect for SPA/API web applications; one where the API is the RP, and another where the SPA is the RP. If you want to use refresh tokens, I think you should go with option 1, but maybe if you care that the API could impersonate the client you'd go with option 2? That still seems like it wouldn't matter to me; that authorization code/access token swap can only be used for a particular application, so it's not like one API could suddenly authenticate as a different backend in that setup. I'm just nervous about going off on my own to structurally alter the setup the tutorial had since this is security-related.
UPDATE
I used the authorization code flow instead of the implicit flow despite the accepted answer, since that's the most recent recommendation of the IETF (see https://datatracker.ietf.org/doc/html/draft-parecki-oauth-browser-based-apps-02#section-4, and a great writeup at https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/). I accepted that answer because using a silent refresh via iframe instead of a refresh token seems to be the most standard approach for what I'm trying to do; using that I was able to build a working system that looks like the tutorial. In fact, the client library it recommends (oidc-client) has a built-in function to handle the details. For completeness, what I'm starting off with is this service:
import oidc from "oidc-client";
import Url from "url-parse";
let baseUrl = new Url(window.location.href).set("pathname", "").set("query", "").set("hash", "");
let redirectUrl = (new Url(baseUrl)).set("query", "redirect=fromIdentityProvider");
let silentRedirectUrl = (new Url(baseUrl)).set("pathname", "silent-refresh.html");
let identitySettings = {
authority: "[my application's id server domain]",
client_id: "[my client's id]",
redirect_uri: redirectUrl.toString(),
response_type: "code",
scope: "openid profile [my application's resource name]",
post_logout_redirect_uri: baseUrl,
automaticSilentRenew: true,
silent_redirect_uri: silentRedirectUrl.toString()
};
let userManager = new oidc.UserManager(identitySettings);
let user = null;
export default {
async logIn() {
await userManager.signinRedirect();
},
async isLoggedIn() {
return !!(await this.getAccessToken());
},
async logOut() {
await userManager.signoutRedirect();
},
async getAccessToken() {
user = await userManager.getUser();
return user ? user.access_token : null;
},
async initializeApp() {
let url = new Url(window.location.href, true);
if (url.query && url.query.redirect === "fromIdentityProvider") {
await new oidc.UserManager({
response_mode: "query"
}).signinRedirectCallback();
window.location = "/";
return false;
}
user = await userManager.getUser();
return true;
}
};
Then in my application I call initializeApp when the app starts and getAccessToken before any API calls. I still need to eventually add the ability to automatically redirect on 401 from the API, but that's pretty easy.
To make the silent redirect work, I created silent-redirect.html based on instructions here: https://www.scottbrady91.com/OpenID-Connect/Silent-Refresh-Refreshing-Access-Tokens-when-using-the-Implicit-Flow. I also integrated Google authentication as an external provider and verified that it also works for silent refreshes, so no trade-off there.
To round it out, for me the answer to my original question is basically "no", I don't want to move the exchange step to the backend. I did also decide to use PKCE even though it seems to me like it shouldn't be necessary, it's in the IETF recommendation I mentioned, so I'll stick with that.
There is a special OAuth2 flow for SPAs - the Implicit grant. If you want just an access token, specify &response_type=token when accessing the /auth endpoint. Alternatively, you can ask for an ID token as well with &response_type=token id_token&scope=openid. The SPA gets the token in the redirect URL from the autorization provider (in the hash part #access_token=...) along with its life-time expires_in=.... So the token stays in your browser - the hash part doesn't get sent to the server hosting the SPA files.
Your SPA should validate and keep both values and before the token expiration, it should call the /auth endpoint in an iframe with &prompt=none parameter. If your authorization provider supports Single Sign On (SSO), then you should get a fresh access token without the user noticing it. So it works similarly to a refresh token, without requiring CORS, PKCE or a client secret.
If you wanted to implement some more sophisticated SSO management, take a look at the OpenID Connect Session management RFC.
I'm creating a mobile app and I would like to provide to the users the option to sign up/in using an email or via their facebook accounts.
I have read so many things in the last two days, but I still don't understand how to do it.
I have seen the example the following link, but it's a little bit confusing for me, and I would like to use Spring (boot) stack, with Java Annotation Configuration.
http://porterhead.blogspot.com.br/2013/01/writing-rest-services-in-java-part-4.html
The best example I found for rest authentication is this http://www.codesandnotes.be/2014/10/31/restful-authentication-using-spring-security-on-spring-boot-and-jquery-as-a-web-client/, but it is form based, which does not work for a mobile application.
The flow of the application in my head is:
Users try to access the app via Facebook (using mobile SDK);
Facebook returns a token, which is sent to my backend server;
Spring security checks if the token is valid. If it is valid, get the user's details (email, for example).
3.1. If that email is present in my database, logs the user in. Otherwise, create a new user.
The steps after that are a little bit obscure for me as well. After these checks, what should I return to the client? How do I validate its token for the following requests?
I've read a lot, but still cannot connect the dots. Any help will be really appreciated.
Thanks in advance!
Firstly when you are sending facebook-auth token to backend,it will checked by facebook library like spring-social,not by spring security. So just i am giving you a example of spring-social.
Facebook facebook = new FacebookTemplate(fbtoken, yourappname);
org.springframework.social.facebook.api.User facebookUser = facebook.userOperations().getUserProfile(); // throw exception if token is not authenticated
if(facebookUser.getId() != null){
return true;
}else{
throw new AuthenticationException(configProp.getProperty("invalid token"), HttpStatus.FORBIDDEN, HttpStatus.FORBIDDEN.value());
}
After verifying facebook auth token,you have to create a unique token for your app,you can create it by
String token = UUID.randomUUID().toString()
then this token you will save in database and return to client end. Further requests from client,you have send this token from client,and now this token it will be checked by spring security.
if(tokenValid){
//access your app
}else{
return "unauthorized user"
}
On logout you will delete it from database as well as from client side
I'm working on an objective-c iOS app. I want to use auth0 for authentication ( https://auth0.com/ ) and I want to use Firebase for the database backend.
I've gone through all the auth0 documentation and I've got authentication working for:
Facebook, Google+, twitter, self registration.
The problem:
The documentation kinda falls off at the point where I need to integrate the authentication model with Firebase, it gives me this one page and I'm not really sure what to now. Has anyone does this integration before and can you lead me down this path? I'm kinda new at this.
BlockquoteConfiguring Token content
As with any other API registered in the dahsboard, Auth0 will issue a Firebase token through the Delegation endpoint. This allows you to exchange a token for another one.
The contents of the Firebase token are generated by convention, copying all properties contained under the firebase_data attribute in the input token used in the Delegation call.
You can generate these very easily with a rule:
user.firebase_data = {
user_id: new Buffer(user.email).toString('base64'),
company: !user.isSocial ? context.connection.replace(/\./g, '-') : null,
foo: 'bar'
};
In the example above, the two properties user_id and company will be generated after calling the delegation endopint, and both will be made available to Firebase.
Blockquote
I have done this for Javascript in the browser, not ios/Objective C. But in concept, you need to do four things:
Setup
Configure your Auth0 account to allow Firebase delegation, and provide your Firebase token. This part is covered by Auth0's ios/objective C docs for Firebase, on the Firebase tab.
(optional) Create an Auth0 rule to set properties on delegated Firebase tokens. You have this in your snippet above.
Auth0 Rule for setting Firebase Token properties:
user.firebase_data = {
user_id: new Buffer(user.email).toString('base64'),
company: !user.isSocial ? context.connection.replace(/\./g, '-') : null,
foo: 'bar'
};
The properties you set here will be available in Firebase security rules.
Authentication Flow
Auth0 has a swift sample that seemed likely to be helpful to you. You need to do two things:
After the user authenticates successfully, make a second Auth0 request for a delegated Firebase access token from Auth0, see sample line 65.
Use the new delegated token with a Firebase object via its authWithCustomToken method, see sample line 73.
My application needs to signup users using Google plus and then display the user's profile data. When the user edits their profile on Google plus and visits my application again, the app needs to show the updated data. Hence the application needs to store the access_token and refresh_token for future use. I want to manage all this using google's js api without any server side google-api-client.
The problem is that I am unable to retrieve the refresh_token using the js api. I have setup a jsfiddle here. The google plus related code is as follows:
$('#signInButton').click(function () {
attributes = {
'accesstype': 'offline',
'clientid': "260932337012-1gdbsh3p7oknkjmeaa7m9q7e6nhhgd9c.apps.googleusercontent.com",
'scope': 'email profile',
'cookiepolicy': 'single_host_origin',
'approvalprompt': 'force',
'callback': signInCallback
};
gapi.auth.signIn(attributes);
});
function signInCallback(authResult) {
alert(authResult.request_token);
}
The refresh_token is not returned inspite of setting accesstype to offline. What am I doing wrong here?
Thanks in advance.
It's impossible to obtain a refresh token using purely the client-side flow with javascript browser based apps. This is a security feature when using the implicit grant type of OAuth 2.0.
The refresh token is for server-side or hybrid flows only.
With javascript only you'll simply need to signin the user again, or if they haven't signed out you can use the 'immediate': true parameter to authenticate them behind the scenes, i.e. without presenting them with another UI popup.
I'm developing a REST service that uses MS Azure Access Control Service for authentication. If the examples are any indication, the typical way to secure a REST service this way would be to provide a global username and pw, private key, or X.509 cert for the protected service. However, I want to use the passive user login mechanism on a mobile device with a flow more like the following:
Unauthenticated user attempts to access protected service from app
Mobile app redirects to browser app (or embedded browser)
User selects identity provider to use for login (facebook, google, etc.) from ACS login page
User enters credentials for identity provider
Browser redirects back to app
App somehow gets the SWT token to use with subsequent REST requests.
I'm stuck at about step 5--getting the SWT token, and the existing examples I've found don't seem to address this scenario. In addition, I'm actually trying to build a proof of concept with a desktop client in WPF, which may complicate things. Can anyone suggest a specific tutorial or a path to pursue that uses the per-user authentication vs. per-service? Thanks.
EDIT:
As I'm digging into this deeper, I've realized that the examples posted below (and most others) are based on OAuth WRAP, which has been deprecated in favor of OAuth 2.0. Can anyone suggest a more up to date reference? Googling has turned up http://blogs.msdn.com/b/adventurousidentity/archive/2011/09/18/acs-v2-oauth-2-0-delegation-support-explained.aspx and http://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=32719 but they're not the most intuitive.
You should look into the ACS Windows Phone sample:
http://msdn.microsoft.com/en-us/library/gg983271.aspx
Here instead of using Silverlight you will be using WPF. Most of the code should be re-usable. Note that since you are using WPF you will need to register your own object for scripting e.g:
[ComVisibleAttribute(true)]
public class NotifyHandler
{
public void Notify(string notifyString)
{
// Here I have the token.
}
}
this.webBrowser1.ObjectForScripting = new NotifyHandler();
Update:
The sample above uses OAuth Wrap to contact the secured service. If you would like to use OAuth2 you should change the way the "Authorization" header set:
OAuth WRAP case:
WebClient client = new WebClient();
client.Headers["Authorization"] = "OAuth " + _rstrStore.SecurityToken;
OAuth2 case:
WebClient client = new WebClient();
client.Headers["Authorization"] = string.Format("OAuth2 access_token=\"{0}\"", token);
You can use the "Simple Service" sample as a guide to implement your token validation in your REST service:
http://msdn.microsoft.com/en-us/library/gg185911.aspx
Yet if you would like to implement a more complete sample you can look at how CustomerInformationService is protected in the CTP version 1.4:
https://connect.microsoft.com/site1168/Downloads/DownloadDetails.aspx?DownloadID=35417
Take a look at this one:
WPF Application With Live ID, Facebook, Google, Yahoo!, Open ID
http://social.technet.microsoft.com/wiki/contents/articles/4656.aspx