hello.js
hello.js
A client-side Javascript SDKfor authenticating with OAuth
Project by Andrew Dodson / @setData
Presentation by Freddy Harris / @harrisfreddy
provider sdk
FB.getLoginStatus(function(response) {
if (response.status === 'connected') {
console.log('Logged in.');
}
else {
FB.login();
}
});
Soundcloud
SC.connect(function(){
SC.put("/me/followings/3207", function(user, error){
if(error){
alert("Error: " + error.message);
}else{
alert("You are now following " + user.username);
}
});
});
no sdk…
hand made
buttonEl.addEventListener('click', function(e) {
var urlGoogleAuth = 'https://accounts.google.com/o/oauth2/auth?client_id=xxxxxxxxxxxxxxxxx.apps.googleusercontent.com&redirect_uri=http://localhost:8081/heart/oauthcallback&response_type=code token id_token gsession&scope=https://www.googleapis.com/auth/plus.login&state=hello'
window.location = urlGoogleAuth
})
var oauthcallback = function(){
if(location.hash){
var params = {},
queryString = location.hash.substring(1),
regex = /([^&=]+)=([^&]*)/g,
m
while (m = regex.exec(queryString)) {
params[decodeURIComponent(m[1])] = decodeURIComponent(m[2])
}
google_auth = params
}
}
var req = new XMLHttpRequest()
req.open('GET', 'https://www.googleapis.com/plus/v1/people/me/people/visible', true)
req.setRequestHeader('Authorization', 'Bearer ' + google_auth.access_token)
req.send(null)
oauth 2
explicit grant
Flow for a website. The access token is kept private on the backend.
implicit grant
Special flow for clients that can't keep secrets.
Authorisation code grant The authorisation code grant is the grant that most people think of when OAuth is described. If you’ve ever signed into a website or application with your Twitter/Facebook/Google/(insert major Internet company here) account then you’ll have experienced using this grant. Essentially a user will click on a “sign in with Facebook” (or other IdP) and then be redirected from the application/website (the “client”) to the IdP authorisation server. The user will then sign in to the IdP with their credentials, and then - if they haven’t already - authorise the client to allow it to use the user’s data (such as their name, email address, etc). If they authorise the request the user will be redirected back to the client with a token (called the authorisation code) in the query string (e.g. http://client.com/redirect?code=XYZ123) which the client will capture and exchange for an access token in the background. This grant is suitable where the resource owner is a user and they are using a client which is allows a user to interact with a website in a browser. An obvious example is the client being another website, but desktop applications such as Spotify or Reeder use embedded browsers. Some mobile applications use this flow and again use an embedded browser (or redirect the user to the native browser and then are redirected back to the app using a custom protocol). In this grant the access token is kept private from the resource owner. If you have a mobile application that is for your own service (such as the official Spotify or Facebook apps on iOS) it isn’t appropriate to use this grant as the app itself should already be trusted by your authorisation server and so the _resource owner credentials grant would be more appropriate. Implicit grant The implicit grant is similar to the authentication code grant described above. The user will be redirected in a browser to the IdP authorisation server, sign in, authorise the request but instead of being returned to the client with an authentication code they are redirected with an access token straight away. The purpose of the implicit grant is for use by clients which are not capable of keeping the client’s own credentials secret; for example a JavaScript only application. If you decide to implement this grant then you must be aware that the access token should be treated as “public knowledge” (like a public RSA key) and therefore it must have a very limited permissions when interacting with the API server. For example an access token that was granted using the authentication code grant could have permission to be used to delete resources owned by the user, however an access token granted through the implicit flow should only be able to “read” resources and never perform any destructive operations.hello.js
modular
<script src="src/hello.js"></script> <script src="src/modules/google.js"></script>
- dropbox.js
- facebook.js
- flickr.js
- foursquare.js
- github.js
- google.js
- instagram.js
- linkedin.js
- soundcloud.js
- twitter.js
- window.js
- yahoo.js
init
hello.init({
facebook : FACEBOOK_CLIENT_ID,
google : GOOGLE_CLIENT_ID
},{
redirect_uri : '/redirect'
})
login
buttonEl.addEventListener('click', function(e) {
hello('facebook').login()
})
login options
hello('facebook').login({
// default is 'popup'
display: 'page',
// default is null
scope: 'email,publish,photos',
// default is init value or window.location.href
redirect_uri: '/redirect-facebook',
// for explicit grant, default is 'token' for implicit grant
response_type: 'code',
// default is true for initiate auth flow, despite current valid token
force: false
})
on auth.login
hello.on('auth.login', function(auth){
// call user information, for the given network
hello( auth.network ).api( '/me' ).then( function(r){
labelEl.innerHTML = '<img src="'+ r.thumbnail +'" /> Hey ' + r.name
})
})
getAuthResponse
Get the current status of the session.
This is a synchronous request and does not validate any session cookies which may have expired.
var fbSession = hello('facebook').getAuthResponse()
var fbAccessToken = fbSession.access_token
var fbExpires = fbSession.expires
api
Make calls to the API for getting and posting data.
hello('facebook').api('me').then(function(json){
alert('Your name is '+ json.name)
}, function(e){
alert('Whoops! ' + e.error.message )
})