I am using the the oauth2 library to impersionate a service account with a user in order to access the google api in the context of that user similar to this example:
function getService() {
return OAuth2.createService('GoogleDrive:' + USER_EMAIL)
// Set the endpoint URL.
.setTokenUrl('https://oauth2.googleapis.com/token')
// Set the private key and issuer.
.setPrivateKey(PRIVATE_KEY)
.setIssuer(CLIENT_EMAIL)
// Set the name of the user to impersonate. This will only work for
// Google Apps for Work/EDU accounts whose admin has setup domain-wide
// delegation:
// https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
.setSubject(USER_EMAIL)
// Set the property store where authorized tokens should be persisted.
.setPropertyStore(PropertiesService.getUserProperties())
// Set the scope. This must match one of the scopes configured during the
// setup of domain-wide delegation.
.setScope('https://www.googleapis.com/auth/drive');
}
As you can see, I am storing the bearer token in the Userproperties and I am wondering if this has some security implications.
Can the user access this token somewhere (afaik there is no UI in the Gsuite for that?)
What can the user actually do with this token (I think it will expire in 1 hour right?)
From the discussions on the comments, I would like to propose the following answer as the current answer.
Q1
Can the user access this token somewhere (afaik there is no UI in the Gsuite for that?)
A: When PropertiesService.getUserProperties() is used, the user can retrieve the saved values on only the same GAS project. And, it seems that the values cannot be retrieved with the Google APIs and UI. Ref
Q2
What can the user actually do with this token (I think it will expire in 1 hour right?)
A: At Google, the default value of expires_in of the access token is 3600 seconds. About this, you can check this using the following curl command.
curl "https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=###"
Q3
if the user somehow can retrieve this token somehow and use this for getting access to services he should not have access to.
A: For the standalone GAS project, when the users have no permission for writing the script, the users cannot directly see the access token (In this case, users cannot use the log.), while the script can use the user's access token.
Note:
Above situation is for July 10, 2020. Google Apps Script and Google APIs are growing now. So these specification might be changed in the future update. Please be careful this. When I could confirm the specification was changed, I would like to update this answer.
Related
I have a user permission system in place where i have a set of permissions within the database, for example
id
Permission
1
POST:CreateBooking
2
GET:AllBookings
And i have another table (junction table) where i put dependent permissions such as
if i want to create a Booking, i need to fetch Package details and so POST:CreateBooking requires the user to also have GET:AllPackages permission.
There's a template system in place as well, where the users can group multiple permissions together and once that template is assigned to any employee, that employee will get THAT set of permissions and it's dependent permissions.
What my nodejs system does is that when user logs in, it fetches all permissions from DB and puts it in a redis set from where on each request, the permission is checked against user id.
Is there any tool from where i can do exactly this but in an intuitive and better way?
I tried keycloak but i don't know how to cover my needs mentioned above.
Thank you
if I'm understanding correctly and trying to generify your scenario, you have a classical situation where:
You have groups which can have multiple permissions assigned;
groups can be created dinamically;
each permission correspond to a specific functionality.
So, implementing the OIDC (Open Id Connect) protocol might fit you needs. As you suggested youself you might be interested in a OpenID provider (do not reinvent the wheel) keycloak is good, you can give a look also to Vault Hashicorp.
So assuming that your backend have an already existing framework to handle security and permissions (eg. Spring Security) you can produce JWT token with the OpenId provider and check throught PreAuthorize claims (permissions) inside the token.
At the end your security layer it's just an annotation you need to insert before your method controller or before you class controller.
Behind the scenes, instead, this is what will happen:
Your user connect to your app;
User insert username and password -> the Open Id provider gives you a JWT
Your Front End app everytime it make a REST req will send also the JWT
The back end controller method called it's under authorization
Given the public keys of the OpenId provider, the validity of the token it's enstablished
If the specific permission claim it's found inside the token, the request can be elaborated else a 403 Forbidden it's returned.
OIDC - as the conceptual model/backdrop to any tool of choice, is certainly a popular/good choice, but as long as you're willing to deal with an element of complexity - the understanding required to implement an OIDC arrangement (- think of it as a possible investment - effort up front with hopefully the rewards tricking-in over time); e.g. OIDC is an ideal choice for supporting SSO (Single Sign On), especially when it comes to supporting/allowing for authentication/login via providers such as Facebook, LinkedIn & Google, etc (- as well as more Corporate OPs (OIDC Providers) including AAD/Azure AD).
Try to first step-back, and consider the possible bigger/future picture, before selecting a tool based upon only your starting/current requirements.
I know that we could use Auth Code Grant, implicit grant or JWT grant. But I have the following scenario:
I have my own app. All users are usually logging in to my app, so I use JWT grant. But sometimes the contract should be assigned from a future employee, who does not have any account yet. Therefore I want to use Authenticaion Code Grant (send him a link via email and he authenticate and assign on DocuSign).
Is is possible to use two different authentication methods for two different recipients in one document/evelope?
I tested each one separelty and works. But both of them in one app?
Yes it is technically possible, but I'm not certain that's the best way to go about this. If you want to generate an OAuth token for a specific user they're required to have their own DocuSign account as they need to provide documented consent for whatever scopes you're requesting.
But to answer your question, an OAuth token gives access to any account that the authenticated user has access to. Once the tokens themselves are generated there isn't any rule or blocker that would prevent you from creating a token for a secondary user and then alternating between the two, as long as the token is used to auth against an account that it has access to. It becomes a little more difficult to keep track of the multiple tokens and corresponding userId -- but you can absolutely do that.
If you want to have one of these envelopes signed by a user that doesn't have an account yet -- I would agree with Inbar that embedded signing would be the correct way to go. Embedded signers aren't required to have their own accounts -- however in order to generate a recipientViewToken you need to authenticate as the sending user. On the customer side what they would see is a one-time-use URL that has a default lifetime of 6 minutes. This URL is typically loaded into a browser tab or some sort of modal window which then takes them directly into the signing session.
If you don't want to use embedded signing and would rather use the email link, you can still do that. Unless you're using a CFR 21 part 11 account users can still sign documents without an account -- they'll just be prompted to sign up for one afterwards so there's somewhere to house the envelope. I think based on this it would be better to use the embedded model, but we can support you on either path.
I would like to create a script to be scheduled in a .bat file that automatically links to google contacts and creates contacts read in a Mysql Database.
I would like a system that does not require any user action.
I know that service-account exist but I have no idea how to create the program. Do you know how to do it?
I hope you can give me a hand.
For the moment, I wish you a good day.
This can be done in three steps if the user is not part of G Suite.
Authenticate the user using OAuth with access_type = offline.
Save the generated Refresh Token.
Use the Refresh Token to generate a new Access Token and then update the account's contacts. The Access Token will be valid (default) for 3,600 seconds.
If the user is part of G Suite, then enable Domain Wide Delegation on a service account and impersonate the user.
This was working fine for many months and now it's just a blank space. I get the following error: Error from Instagram: The access_token provided does not match an approved application. How can I get a new access_token for an existing client??
You need to check you application hasn't been put into sandbox by Instagram. They made big changes to their API on the 1st of June and if you had it submitted your app for review it will be put in sandbox mode and only sandbox users will be able to use it.
Even if you are not in sandbox mode you may need to get your users to reaurhorize your app due to new scopes being used to control access to everything other than basic user information.
Check Instagram Developer Docs for more information on the changes
You need to check your Access token's Scope and asking for login permission
where some new Scope had been added ex:public_content Added. Also don't forget to check for requirements Scope for API you are using and if it's need and Authentications "Valid access Token". where also had some changes.
basic - to read a user’s profile info and media
public_content to read any public profile info and media on a user’s behalf
follower_list to read the list of followers and followed-by users
comments - to post and delete comments on a user’s behalf
relationships - to follow and unfollow accounts on a user’s behalf
likes - to like and unlike media on a user’s behalf
And take look about **Sandbox API behavior of your application not life yet :**
API Behavior
The behavior of the API when you are in sandbox mode is the same as when your app is live, but comes with the following restrictions:
Data is restricted to sandbox users and the 20 most recent media from each sandbox user
Reduced API rate limits
The first point is important and it means that the API behaves as if the only users on Instagram were your sandbox users, and the only media ever posted were the last 20 for each of these users.
For example, if you query the /users/{user-id}/ endpoint and the {user-id} is a sandbox user, then you will get the normal API response; but if the {user-id} is not a sandbox user, you will get a APINotFound error.
As another example, let's consider an endpoint that returns a list of media: /tags/{tag-name}/media/recent. The response returned by this endpoint will contain only media with the given tag, as expected. But instead of returning media from any public Instagram user, it will return only media that belongs to your sandbox users, restricted to the last 20 for each user.
Good luck
The following video clearly explains what steps to follow to get this working with the new auth
https://www.youtube.com/watch?v=0k4RhTS94Hw
Kind Regards
Sandeep Sahoo
We have a client who has a simple Instagram feature on the site to pull photos by a certain tag. They just noticed it isn't working. Getting an error - invalid access token. I guess since the 1st because of the updates. We didn't used to need an access token since we're not doing anything with users - just tags.
Now it looks like we need one and the documentation makes zero sense on how to obtain one. And it seems like they're not accepting most apps. The app is in sandbox mode too. So I'm assuming it's because it got switched to that? Got no notification of this happening.
The first step in documentation to get an access token is "Direct the user to our authorization url." What does that even mean? There's not a link provided or anything. It also says "Company Name, Contact Email and Privacy Policy URL are required to start a submission." Our app doesn't have a privacy policy... it's just a simple tag feed. I don't understand why everything is so complex to have a simple tag feed.
Is there a wait time to get the app approved..if it gets approved... Do I have to have it approved before getting an access token? This isn't outlined anywhere.
You got it right. As of June 2016 any Instagram API calls require an access token.
Getting an access token is described in the documentation. App approval is not required.
There are two ways to get one: server-side or client-side. The second option (called implicit authentication) can only be used when implicit OAuth is enabled in the client settings (Manage Clients > Edit Client > Security > Disable implicit OAuth). It is disabled by default.
In either case you need to redirect the user to the authorization URL to obtain an access token.
The URL for explicit mode (server side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
The URL for implicit mode (client side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
After this you will be redirected to the REDIRECT-URI, which will be passed an argument. For explicit mode this will be a query string with a code, while for implicit mode you will get the access token directly as a hash:
http://your-redirect-uri?code=CODE
http://your-redirect-uri#access_token=ACCESS-TOKEN
For implicit mode you can then get the access token from the window.location.hash in Javascript.
For explicit mode, however, you need to further process the code to obtain the access token. You can read how this can be done in the API Documentation. I'm not going to take this any further here.
The problem is that every user who wants to see your feed needs to login to Instagram (and have an account) in order to view it. In your case this might not be desired. However, there are a few options to get around this (rather annoying) problem:
You can reuse your own (already obtained) access token(s) to display the Instagram feed for every user. You will need to be aware of rate limits for each token. For sandboxed apps this is 500 API calls / hour, while live mode allows 5000 API calls / hour. [source] You could store tokens in a table and use them in a round-robin manner, to allow more API calls. This involves manually obtaining a bunch of tokens which your application can use (the more the better). This might not be the ideal solution considering Instagram doesn't warrant access tokens to have an unlimited lifetime.
You can retreive JSON data without authentication by appending /media/ to a user page URL, as described in this post. No tokens or client IDs are required for this to work. However, this only works for users, not for tags. Besides, Instagram doesn't document this feature so it is not garanteed to work in the future.
You can use an aggregator like Juicer or Dialogfeed instead which will handle access tokens for you. This is usually not free of charge.
I'm also in the process of making an Instagram feed for my website, and this is what I concluded from my research. Please bare with any errors I made.
Edit: Here are some more limitations for sandbox apps.
In sandbox mode you can only access data from sandbox users (thus users who received a sandbox invite). This means that:
Media retreived by user, e.g. /users/{user-id}/media/recent, will return an empty response if the user is not any of the sandbox users.
Media retreived by tag, e.g. /tags/{tag-name}/media/recent, will only contain tagged media belonging to sandbox users.
Thus, for a tag feed to work, it needs to be live (reviewed and approved). If you don't want to do this, the only alternative is to use an aggregator as I mentioned above.