I'm supporting an installed application, a standalone desktop application. I would like to enable people whos use this application to send out emails using their Yahoo email account.
I know that I will need to create an application in Yahoo Developer Network, then generate a URL to request a Yahoo OAuth2 token first and then use this token, I can use SMTP or OpenID API to send out emails.
I've encountered a lot of problems while creating my application in Yahoo Developer Network, and requesting the token. I've compiled them and I'm listing them below:
Confidential client or public client:
Yahoo explains that one should choose confidential client for traditional web application and choose public client for mobile apps, native apps, or single-page apps.
If confidential client is selected, there will be client secret generated; and if public client is selected, there will be no client secret generated. Plus, if I choose public client, which I did for my application, when I request OAuth2 token, I can choose to not include client secret as one of the parameters and it looks like that that is not causing any problem.
API Permission:
I took it as scope. But the strange thing is that it does not include anything like Google. Google states "Send email on behalf of customer", but similar choice in Yahoo is like OpenID Connect Permissions-Email, which has a brief introduction as "Access to email address and verified status".
There is another possible choice for OpenID Connect Permissions, as well. It's called Profile, having a brief introduction as "Access to common profile information (eg. first/last name, gender, etc.)".
Another strange thing about permission is that when I started to request OAuth2 token by opening a generated request url, after logging into my yahoo account, the page stated the permission as "Read Profile", which does not meet our expectation, as I took it. Plus, it does not have anything like sending email on behalf of customer.
Redirect URI:
In Yahoo developer center, for the application I created, I set it to localhost, port 55555, the same as I set for Google OAuth2.
I have reviewed some code examples, the code uses the secret, the stuff that only exists for confidential clients, or traditional web application, and stated that I need to develop a redirect web page in our website, which redirects to localhost, port 55555.
Redirect URI is also a required parameter when generating the OAuth2 token request url. If I state localhost as the redirect uri inside the requesting url, Yahoo page says "Oh, no. There had been some problems, please try again. Developer: Please send a valid request."
If I set the redirect uri to "oob", which means "out of boundary", as stated in Yahoo OAuth2 Guide, the generated url will succeed, but the same page shows up again after I login to my Yahoo account and grand the permission requested. Well the permission is also wired. It's "Read Profile", nothing about email sending.
I have searched Internet to find out what exactly those settings should be set for my scenario and read thoroughly through Yahoo OAuth2.0 Guide. But nothing is clear enough for me to do my coding job. Could anyone shield some light for me? Thanks in advance.
Plus, I'm thinking of getting help from Yahoo regarding this task, but it seems that they do not have any communication channels for developers like me. Anyone knows more about that and would like to share with me? Thanks, again.
Related
I'm creating an OIDC provider with oidc-provider. For now, my Registration flow required email verification step, which is handler outside oidc-provider. This approach works but it leads to an issue that user can not automatically login after setting up their password.
I thinking of creating a new prompt policy name email-verification, something like:
https://<auth-endpoint>?client_id=...&prompt=email-verification
I wonder:
Is this flow acceptable with OpenID Connect specs?
Is there any document, tutorial or example in terms of specs or implementations of this approach?
The case user register in mobile app, but open email link in web (we have a mobile app with different client_id and of course, different redirect_uri. What should we redirect user to the app without error.
Thanks,
I find setting up the auth services for every website is cumbersome.
This is my scenario: I have currently three websites for example example.com, example.org and example.space and their mobile apps respectively.
I found it's tiring to configure auth for each of them separately. What I want is to create a centralise auth service running on a different port with a different database. For example on example.net:7000.
Whenever users request to be authenticated by sending their email and password to example.com/auth, example.org/auth or maybe just example.net/auth they will receive a JWT token which can be used to access the protected resources on the respective sites or their mobile apps. And it should be without opening any website from the browser in case of the mobile apps.
I mean users shouldn't be aware of this process that their credentials is being handling by a single server. It's kind of like Google where user can login on to gmail.com and also gets logged in to google.com.
I have taken a look to Openiddict but found out that it has some redirections involved (to auth a user, the user is being redirected to the auth server and then send back to the previous url). I want it to be like machine to machine communication with no user interactions involved rather than sending an JSON containing their credential in a simple HTTP POST API request.
How can I achieve this? Is there any example repository.
Note: I am using Flutter for the mobile apps.
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
I'm working on an iOS application and what I'd like to do is have the app ping one universal Gmail account to check for the most recent email.
I went through the guide from Google at https://developers.google.com/gmail/api/quickstart/ios?ver=swift, but the result did not work. After some googling, it appears that some functionality may have been changed, but they haven't updated their documentation yet.
Is there a way to send credentials via https to Gmail and get email messages back? I have an OAuth key via the Gmail API manager, but when I pass it as "access_token", the response says "Login Required".
AFAIK, an error response "Login Required" can be encountered if you try to list the buckets for a project that do not provide an authorization header.
If we check Users.messages: get, it's noted that it requires authorization.
For this, you may want to check Authorizing Your App with Gmail wherein you will find these basic authorization pattern:
During development, register the application in the Google API Console.
When the app launches, request that the user grant access to data in their Google account.
If the user consents, your application requests and receives credentials to access the Gmail API.
Refresh the credentials (if necessary).
Furthermore, if your application needs to access Google APIs on behalf of the user, you should use server-side flow. Please see Implementing Server-Side Authorization for more information.
Sometime back I was involved in writing a sample application to access email from gmail but using C++ on windows. The code is at https://github.com/Panchatcharam/simple_gmail_api. I was able to successfully get emails.
When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application.
So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,...
This is not managed by OAuth2 ? Or I missed something ?
For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key.
There's no good answer. Native app callbacks typically happen via custom registered URI schemes (e.g.: callback redirection URI is something like: myapp://oauth?code=xyz123). Unfortunately, any app can claim ownership of a given protocol scheme and receive the callback.
This problem is very synonymous with trying to lock down any protocol with "trusted clients". Think of the IM networks battle to lock out 3rd party clients (in early 2000's). Eventually they gave up - since whatever client & protocol endpoints are deployed could be reverse engineered by 3rd party developers.
Note: There is also some active discussion on this topic on the OAuth WG mailing list: http://www.ietf.org/mail-archive/web/oauth/current/msg08177.html
Normally client_id is associated with site's URL - OAuth responses/redirects will be sent only to the registrated Url. So attacker will not be able to receive results of the request on own site (unless somehow your and attacker pages are on the same domain).