I'm developing an iOS app that uses the Magento REST API, I'm following the documentation provided by Magento for the OAuth authentication (http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html)
I use the initiate endpoint to get the request token but then when I want to authorize this token I need to use the "authorize" endpoint and there I get redirected to a URL where I have to provide customer credentials to authorize the request token. This is not the behaviour that I was expecting since the user would be already logged in using the app's login (not implemented yet). Is there a way of making this "authorization" step transparent for the user? Like calling some service passing it the user's credentials provided in the login screen of my app?
If there is no way I'll use the Magento's SOAP API
I did that too really really painful Magento use OAuth1.x, basically you've got three options:
Do it yourself
Use some oAuth consumer lib, you can find them on github
Use MKNetworkKit with this add-on
I used the 3rd because oaf MKNetworkKit, and anyway there was still a lot of work to do, if you want to hide some passages injecting js.
Related
I am working on migrating Docusign basic Authentication to OAuth2.0. I followed the article How to get access token with JWT grant authentication.
However, I am confused when trying to get the eSignature working.
Our current flow is:
We don't use a phyiscal document file, instead we use a template (templateId) that we uploaded to docusign ahead of time. Then when we make an API call, docusign returns an external url that we use to direct the user to sign the form. After the user signs the form, Docusign uses the return url that we provided to direct the user back to our application.
Any ideas which method that I should use to achieve it? With Docusign Oauth2.0 migration, we only need to update the authentication piece, we do not need to make different API calls. In other words, We can continue to use restapi/v2 with OAuth2.0 authentication, everything else will work as before. right?
However, I noticed that the legacy login URL still requires api_password
https://www.docusign.net/restapi/v2/login_information?include_account_id_guid=true&api_password=true&login_settings=all
If we do have to call restapi/v2.1 Docusign REST API along with OAuth2.0, in this article How to request a signature using a composite template. At the end, the article shows that its expected response URL.
"url": "https://demo.docusign.net/Signing/MTRedeem/v1/09f2e35e-xxxx-xxxx-xxxx-1fbc6fcf77ed?slt=eyJ0eX...i3x-4g"
Any inputs would be really appreciated! Thank you!
You can still use the same URL from the eSignature REST API v2.0 to make all API calls to DocuSign, except the login_information call in your post.
The rest of your scenario - using a template, redirecting the user etc. - can be done just the same with your access token obtained using OAuth 2.0
To get the user's information with OAuth you use the getUserInfo() call and you can read all about it on the developer center.
(the URL is https://account.docusign.com/oauth/userinfo)
I have really hard time trying to understand mostly how should I implement my authorization flow. I think I have the authentication flow mostly correctly implemented using the technologies I've listed in the title. Here's what I want to achieve:
Basically I have a mobile app built using React-Native and I have made a restful API for this mobile app to use. I am currently at the point that I have implemented authentication using ADFS 4.0. My mobile app directly uses the ADFS endpoints to authenticate the user and I am able to receive the id_token and access token correctly from there. But here comes the part that I have no clue what to do next. Before I used openID, I had my own authentication and just an OAuth2 flow in my Spring REST Api and everytime I made a request from the mobile app to the API, I provided the access token in the headers, and used it to verify from the authorization server that the user is indeed authenticated and also received some crucial information about the user to use in my API. But now since I use OpenID-Connect and ADFS 4.0 for the authentication, I have the cruicial information I need in my API in the id_token. The question is, what exactly should i send to my API now from the mobile app, the id_token, access token or both? Given the access token to the userinfo endpoint at the ADFS returns the subject of the owner of the token. Like is there any way I could receive the users info using the subject or what exactly should I do. I've tried to research this subject a lot, but I am still very confused..
Send the access token to the API in the Bearer header. In the API, validate the token and, if required, do user info lookup. A Spring example of mine here if it helps.
Happy to answer any follow on questions ..
I'm new to Auth0 and having real trouble wrapping my head round it. My app is going to be built using React, packaged using Phonegap.
Am I able to use Auth0 with a completely custom UI for creating accounts, logging in etc.?
Ideally my signup flow would be...
User Signs up using my react form
Details are sent to my API and then passed to Auth0
Success message is received from Auth0 and the user is mirrored in my local DB
My ideal login flow would be...
User fills in email/password on my custom form.
Details sent either directly to Auth0 or via my API
Token is sent back and stored in localStorage
Then each request to my API...
React attaches token to every request in header (actually Axios interceptor does)
My API is able to verify that the token is valid and not expired
API performs request.
Not sure how to deal with social logins, claims etc. but that's for another day, basically I want to do everything through the API and not use their lock screen etc. Is this possible?
Yes! That is definitely possible and to achieve this you would want to use 'Resource Owner Password' grant type.
Once you collect the credentials from user in your custom form, you can directly pass those to Auth0 by calling an endpoint - 'https://yourapplication.auth0.com/oauth/token' with all the necessary parameters. You can make a simple POST request to this endpoint from you client application. For ease of use, there is a javascript library provided by Auth0 for all of their endpoints- (https://auth0.com/docs/libraries/auth0js/v9).
Auth0 will return a token which can be used to call your server side APIs by passing it to the request header.
So to conclude, you can do it through API without using their lock screen.
Let me know if you need any further help. We can discuss on social logins and claims also.
I have a 3-legged auth flow working on a web app of mine. It goes as follows:
Use clicks Connect with Google
They accept on the OAuth dialog that Google Provides
The page gets redirect to my backend's /oauth/google endpoint with a code parameter which I send to Google to get a refresh_token so I can access data (like calendar info) on their behalf
I redirect back to the web app passing my own JWT token in the URL.
Whenever the web app makes a request like api.mybackend.com/me they use the JWT token I provided
I'm trying to accomplish something similar in a mobile app. What's the acceptable way to do this? Is it pretty much the same logic?
If it helps, my backend is Ruby on Rails and I'm writing the mobile app in Swift.
Thanks!
If you're using NSURLSession to make HTTP requests, then see this for information about handling redirects.
Google also has some pre-built Google Sign-In packages for iOS and Android that you can include in your app, similar to the one in your web client. I've never used them though, so I don't how exactly they'd integrate with you app.
Alternatively you can set up an authentication endpoint in your backend that handles the whole thing, with the app only ever making one request to your server and your server handling communication with Google. So, for example, you could have the user submit a request to /oauth/mobile. The server then submits an authentication request to Google and gets an access token and a refresh token. Then you can return your own app's token from the server. Google has some documentation on Google Sign-In for server-side apps that may be relevant.
For my current work project we're trying to use OAuth to secure a mobile API, but the app doesn't have user accounts, so authentication would take place invisibly from the user, where the app will send up some secrets to the server and receive the token to be used for subsequent web service calls. The problem is, all the libraries and tutorials I can find implementing OAuth follow this pattern:
Present a web view allowing a user to login
Receive a callback to a custom URL scheme, and parse the necessary information to authenticate future web service calls
How do I achieve this without the webview step? I should be able to make an HTTP request directly with the correct credentials which will return the necessary authentication details.
The app will use OAuth 2.0
It is not clear what do you mean by
the app doesn't have user accounts
If you want to call some API on behalf of user you should ask him for a password. Doing it in webview or not depends on provider implementation. For example, twitter doesn't force you to do that.
In other case, if you want to call service on behalf of client, take a look at this answer: https://stackoverflow.com/a/7477112/2283405
If the app doesn't require "personalised" or "user-specific" data to be manipulated, then you can probably try using "client-credentials" grant type to obtain access tokens using the application credentials granted upon the application registration process by the Authorisation Server (for e.g.: OAuth server) that's there in your environment. The idea is that, your app is what basically authenticates with the Authentication Server for you using the aforesaid credentials (i.e. Client Consumer Key and Client Secret Key).
NO, you have to do login compalsary. if you try without. it won't be possible.