I have been trying to create an authentication in Laravel that is based on simple verification via an external services API key. The external API will provide me details like the username associated with the account a user should only have to supply an API key to login. No password, email, or username required.
Looking at Laravel's documentation it seems like using something like they demonstrate in the "Manually Authenticating Users" section may be most applicable. My problem is that this still appears to be based on a email + password credential model.
What is the proper way to modify/extend the frameworks authentication system to use an API key. If I use this manual authentication model I would be able to connect to the API and verify the user but I don't know the best way to modify it to accept an API key and username as the "credentials" for a new account (username would be coming from the API response data).
Related
As my app is designed using flutter and all my app endpoints are created using Springboot. So can call direct APIs using Feignclient in Springboot to create my own endpoint to list all the envelopes for one recipient?
Do we have any endpoint to get all the envelopes by using the recipient name or email id? for example XYZ user needs to sign in 2 envelopes then using XYZ can we be able to fetch those 2 envelopes?
Yes, you are very welcome to call the eSignature REST API directly and not use an SDK. Use API version 2.1. About half of the developers who use the API do so directly.
Updated: authentication
To call the eSign REST API, each of your API calls must include authentication via an access token. You can obtain an access token via an OAuth flow.
If your users have DocuSign user accounts, then they should login/authenticate via Implicit grant assuming that you're using Flutter for a mobile app.
If your users don't have DocuSign accounts (they are signers, not senders), then you need to have a backend server that can securely use the JWT grant flow to obtain an access token on behalf of a "system" account such as "finance#example.com"
If you have questions about authentication, please open a new question on StackOverflow.
https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopes/liststatuschanges/
This endpoint has lots of filtering options including:
email={email_address} Limit results to envelopes sent by the account user with this email address.
user_name must be given as well, and both email and user_name must refer to an existing account user.
user_name={user_name} Limit results to envelopes sent by the account user with this user name.
email must be given as well, and both email and user_name must refer to an existing account user.
Suppose I have an application in which I have enabled (google) Oauth2 authentication but I want only a few business people can log in to my application with there specific email id and rest of the people can't. How Can we achieve this using Oauth2?
1.) Lots of people have a Google account and can authenticate with Google
2.) I want Only some of them should be authorized to use your app, which maybe deals with business assets
I suspect your requirement is:
Lots of people have a Google account and can authenticate with Google
Only some of them should be authorized to use your app, which maybe deals with corporate assets
In this case I would proceed something like this:
STEP 1: PREREQUISITE USER SETUP
Get a list of users and perform an Administrator Approval step to create them in your product database, perhaps with Name and Email fields.
STEP 2: INCLUDE THE EMAIL SCOPE DURING LOGINS
In the Google login redirect, use scope='openid email' so that you can identify the user via email after login. Allow users to successfully authenticate.
STEP 3: AFTER LOGIN PROCESS THE ACCESS TOKEN
You will then get then be able to get the user's email address from the access token (though you may have to send it to the Google User Info endpoint).
STEP 4: DENY ACCESS WHEN REQUIRED
If you can't find the email associated to the token in your product user data, present a Forbidden message to the user.
FURTHER INFO
See my User Data Write Up for further details on technical options. Note that I have not actually tested this with Google, but I have used the general approach with a few different systems.
I am trying to be able to set up a cron job to read contents from a certain email in my gmail inbox daily. I lookeed up gmail api documentation and noticed that the only way to authenticate my requests to access email data is via OAuth 2.0 which requires user authorization. Is there a way to authorize my app to access emails from a particular email id without the need for the user to manually take any actions.
I found this: https://developers.google.com/identity/sign-in/web/server-side-flow. I was wondering if there is any way to follow this workflow without having to build the UI?
Technically speaking you can use Oauth2 you just have to have the user authentication your application once. You will get a refresh token then you can use the refresh token to get a new access token from cron. Unless this is a Google domain account you cant use service accounts. There is no way to pre authorize a service account to access a normal user gmail.
Alternative: have you considered going directly though the mail server? Skip the rest api. https://developers.google.com/gmail/oauth_overview Note: That page also speaks of XOauth2 I haven't tried it yet you can still access SMTP and IMAP using username and password.
Currently I am developing an application with several access methods based on Laravel/Socialite, I want to allow users authenticate with facebook, twitter, google so far or creates it's own account by filling a form with name, email, password.
Routes
login/
login/facebook
login/twitter
login/google
Questions :
¿What is the best approach once the User data has been obtained from the auth provider?
¿How to handle a common data user storage?, I mean, I am storing only person name, email and avatar, but how about the token provided by the auth process.
¿How to handle when user log in with more of 1 providers with a same email address?
And how to handle when a user set password to his account created trough facebook?
I thank your attention .
I'm trying to implement OpenID authentication for my site. Here's the scenario:
I want the user to be able to
login using just openId(user can just get verified by visiting openid provider. no need to create a custom account with email-password),
Via email/password (user has registered in site by filling out a form)
Attach open id(s) to his/her accounts (openids + email for one account).
Now I don't know what credentials I should store for open id. and not sure about the DB schema. Here's the database schema:
Table: Users
UserId => PK
... => Custom info. Not related to authentication.
Table: Authentication
AuthenticationId => PK
LoginId => (when custom site membership => email address) (when openId => openid unique address)
UserId => FK to Users.
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address)
Password => filled when using custom membership. empty when using open id.
Now when a user logs in, whether by using openid/custom membership, I just look at authentication table and look for credentials and get the appropriate user. If no users exist, I create a new user and add an entry in authentication table.
The main question: Is storing Provider and LoginId (see the above comments to see what is being stored in these fields) enough for storing openid authentication? Should I store any additional data so that when the user returns I can authenticate him/her based on my saved data?
Do you suggest any other (more efficient) approach to implement this?
Thank you.
Store the ClaimedIdentifier for the openid user--not the Provider address. The Claimed Identifier is what the OpenID protocol verifies is unique for the user and also potentially provides portability across OpenID Providers.
Also, because OpenID 2.0's Claimed Identifiers may be deprecated by OpenID Connect (an unfinished successor to OpenID 2.0), it may also be in your best interest to record the OpenID Provider Endpoint URI and the email address asserted by the Provider in the user record. For now, do not use these as part of your authentication flow, but by recording them, you'll be able to later determine which email addresses you 'trust' (i.e. suppose you decide email addresses asserted by Google are trustworthy) and allow the user to thereby migrate their account to an OpenID Connect one using that verified email address. This will also mitigate against the danger of your web site's Realm (usually http://yourdomainname.com) changing and causing all your Google's user Claimed Identifiers to change, which can only really be recovered from via their email address, tragically.
I also recommend you use different tables for the different auth types. There are a couple of advantages here. The most important one is that architecturally it makes it more difficult to have introduce a security hole into your web site that might allow someone to enter in (for example) an OpenID into the username field and a blank password and have it show up as a database match and login without any real authentication happening. Secondly, it provides a more flexible model in case you want to add a third authentication mechanism rather than making your 'Authentication' table grow horizontally for all users. For example, OAuth 2.0 and "OpenID Connect" will each probably introduce new types of authentication to your site when you add support for them over the years, and adding new tables to handle the new types of data seem to fit better.
We just store the openid claim url. You may want to request additional information from the provider such as the user's name. The most important thing is to separate membership and authentication.
Our schema was
Profiles
--------
UserId
FirstName
LastName
etc.
Users
-----
Username
Password
Profiles.UserId is simply a string property that stores either the users internal username or their openId claim url, depending on how they registered.
Upon successful authentication (either using an internal username/password or external provider) we just set their authentication cookie using either their internal username or their claim url. Getting the user's profile is then just a matter of finding the profiler where (UserId == User.Identity.Name).
This has the advantage that a user can choose to change how they authenticate at any point (perhaps switching to an internal account or using a different provider).