I'm currently trying to add google sign-in support to our educational website. The majority of time users will just sign in with Google, but occasionally teachers need to be able to import pupil rosters from Google Classroom too. I've got all of this working using the guides from the Classroom developers site (https://developers.google.com/classroom/quickstart/js). I'm using https://apis.google.com/js/api.js to sign users in (gapi.auth2.getAuthInstance().signIn) with just the "profile" scope and then granting the extra classroom scopes if teachers need them.
I'm just reading the Migrating to Google Sign-In guide (https://developers.google.com/identity/gsi/web/guides/migration) and trying to work out if it applies to us or not. It's explicitly saying not to use gapi.auth2/gapi.client etc anymore and to use the new Identity Services Library instead, but there's no explanation how to use that to make API calls to Classroom (or any other Google API). The OAuth 2.0 JS guide (https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow) is still saying to use gapi.auth2 etc too.
So should I be using the new library to sign users in, instead of api.js?
And if so, am I still supposed to be using gapi.auth2 to make API calls, or should I be using the new library instead somehow?
Authentication for sign-in, and authorization for data access are being separated. Use the new Identity Services library for sign-in instead of api.js and the profile scope. This should be the case for the majority of your users based upon what you've shared.
Later, and as needed, continue using gapi.auth2 to obtain an access token and call the Classroom or other Google APIs.
Functionally, what this will look like is separating out your sign-in flow using HTML or JavaScript from gapi.auth2 and access/refresh tokens. Token requests for calling APIs (using either implicit or auth code) would be made only at the point they're needed. Say you'll use 3 different scopes at some point, each would be requested only when necessary, also known as incremental authorization.
Related
I'm designing the architecture for a college project and I don't know how to deal with the user authentication and authorization part of it. The project is a desktop Electron app which would need two types (hence the roles) of users. They both need to be authenticated in order to use the app, and depending on their identity, they will have different authorizations. Since the project is meant to be used by teachers and students as part of a laboratory class after it is done, I don't think more than 30 people will be using it at the same time.
My first thought was using a PostrgeSQL database in AWS for this and implementing the authentication myself, but this means that users will have to sign up and create a new profile, which means remembering yet another <username/email, password>. Trying to avoid this, I read a bit about OAuth 2.0 and OIDC, and how it can be used to authenticate and authorize users without implementing either of those tasks oneself, but rather delegating the task to OIDC. I created a free account with Auth0 and thought about using it for the OIDC integration but after reading about 40 pages of an "OIDC integration handbook" they offer for free, I could not know if I would be able to distinguish my user base through these roles or tags as I mentioned. I just followed the steps in the tutorial handbook and tried to understand how the auth flow worked, but that didn't give me any information on my question.
So all in all what I want to know is: is it possible to implement this with Auth0 (free account) without having to use a third-party database solution (such as PostgreSQL with AWS)? If not, what would you recommend me to look into? Preferrably a solution that will let me discriminate between the two types of users BUT at the same time taking advantage of the OIDC implementation of Google for example.
There are 2 separate solutions here:
DESKTOP AUTHENTICATION
The 2 standard requirements are:
Use Authorization Code Flow (PKCE)
Login via System Browser
You listen for a login response via one of these mechanisms (I prefer the latter):
Loopback web server
Private URI scheme OS notification
My blog has some tutorials + code samples that use Electron. You can run both of the above listening options and see what you prefer.
API AUTHORIZATION WITH ROLES
You need to make roles available to the API via claims. This can be done by either of these mechanisms (I prefer the latter):
Including roles in access tokens via Auth0
Get the API to read user roles from its own database
My Authorization blog post discusses building up a claims object in an easy to extend way. The main objective is usually for API OAuth processing to result in an object something like this:
class UserPrincipal {
// The technical user id from the access token
string sub;
// The user id from your own database
string userId;
// The user's roles
string[] roles;
}
Given that object you can do things like this:
Use role based authorization when needed
Serve up user resources after login from your application data
TO SUMMARISE
Auth0 will meet some of your requirements and may be all you need in the early days. You will probably need to manage non OAuth user data in your API at some point though.
Happy to answer any follow up questions ..
Is it possible to use Smartsheet's API to sign into Smartsheet on the Web. I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this? or is this even possible with the tokens that can be produced by the API. I am aiming for a web based single sign on without using SAML.
I'm not totally clear on what you are asking, so I'll address each question individually in hopes that it addresses your overall question:
Is it possible to use Smartsheet's API to sign into Smartsheet on the Web?
No, you cannot create a web session using the api. For 3rd party apps, that would defeat the purpose of using OAuth2 since the whole goal with OAuth is to grant limited access to protected resources. For user-generated access tokens, it could be feasible, since those tokens have unrestricted access, but the API does not currently support that.
I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this?
I assume you mean you will create a form to collect a user's Smartsheet credentials and use those to have an SSO experience into Smartsheet? This is technically possible, but I'd strongly discourage against it. To create an SSO experience, you'd need to retain the password in a way that allows you to POST it on behalf of the user. This means you'd store it in a 2-way encrypted state (at best), which is definitely not best practice. Again, I'd highly recommend NOT doing this.
I am aiming for a web based single sign on without using SAML.
If you want an SSO experience into Smartsheet, you can either use SAML or Google (not truly SSO, but pretty close). There isn't an API-based approach currently.
Side note, if you want to go the other way, meaning you have a website and you want to use Smartsheet (or any OAuth2-based API for that matter) as the identity provider, you could use the 3rd Party OAuth2 flow. See the docs here. You could then add a "Login with Smartsheet" button to initiate that flow, much like we see everywhere on the web with "Login with Google" or "Login with Facebook".
I would like to programmatically query the Flickr API using my own credentials only just to grab some data from there on a frequent basis. It appears that the Flickr API is favouring OAuth now.
My question is: how should I authenticate the API without user intervention just for myself? Is it possible any more?
Once you have received an oauth_token (Access Token), you can use it for multiple subsequent API calls. You should be able to persist the token in a data store (I haven't done this myself) and use it even after your application restarts. Of course, you still need to write the code to get the Access Token the first time.
If your application is already coded using the old authentication API, it looks like there is a one-time call that you can make to get a new-style Access Token. See http://www.flickr.com/services/api/auth.oauth.html#transition
Even if you don't have a coded application, you might be able to use the API Explorer for any of the calls that requires authentication (flickr.activity.userComments, for example) to harvest an api_sig and auth_token.
The scenario which you are describing is sometimes referred to as 2-legged OAuth. (https://developers.google.com/identity/protocols/OAuth2ServiceAccount)
Google APIs support this via a 'service account'.
Unfortunately Flickr doesn't seem to support this kind of interaction.
For public data interaction (like downloading your public photos (photostream) from your account), there's no need to authenticate. You can get the data using only the Flickr user-id.
For other interactions (like downloading private photos (camera roll) from your account), you'll need to follow the full OAuth procedure at least once.
I want to use the Linkedin API to get details of jobs posted by any company. This data seems to be public, so do I need to integrate Oauth?
The LinkedIn API isn't designed for developers to grab information and present it to people who haven't authenticated (public display). Making calls as a single authenticated user to store it or present it elsewhere is against the Terms of Use for the API. Additionally, you can't store the data you get - it's just designed to present to the authenticated user.
If you want to use the API to present this information, your users need to authenticate with LinkedIn and then you can make the call on their behalf. This is probably easiest to do using the Javascript framework.
The data is not quite public. You need an API key and you need oAuth to make API calls. Probably you dont need it if you just want the public profiles. Read the docs (RTFM).
http://developer.linkedin.com/rest
http://developer.linkedin.com/documents/job-search-api
I'm trying to get access to the Google's todo feed with this url:
https://www.google.com/calendar/tdl?secid=<SECID>&tdl={%22action_list%22%3A[{%22action_type%22%3A%22get_all%22%2C%22action_id%22%3A%221%22%2C%22list_id%22%3A%2215052708471047222911%3A0%3A0%22%2C%22get_deleted%22%3Afalse}]%2C%22client_version%22%3A-1}
If I open this in my browser with a correct secid, it shows me right what I want.
Now, the question is: how do I get secid programmatically (specifically, in a java program)? I have access to the authToken (from CalendarService), but I have no clue how to use it to authorize my access to the URL above.
I tried to use the url http://google.com/accounts/ServiceLogin, but I didn't find any examples.
Any help, please?
From what I read secid is a session ID obtained from browser's cookies. Whereas your case uses Java which implies a server app. If that is the case, you want to drop the idea of using secid entirely.
Instead, you want to check out Google's OAuth2 documentation. If you are using Java, most likely you would be interested in the web-server OAuth flow. Pay special attention to the sequence diagrams.
The key steps include:
1) Obtain an authorization code from Google OAuth with the user's consent. For that, you redirect the user to Google with the appropriate scope. Check the list of calendar scopes for your case. Once the user consents, Google redirects back to you with an authorization code.
2) Call Google OAuth with the authorization code and your app's credentials to exchange for an access token.
3) Call Google's Calendar API using the access token.
And if you use Google's Java client as suggested by #ChaosPredictor, chances are some of the steps are already wrapped into the Java client (and your code will be much simpler).