I am creating web and mobile apps that reimplement an existing desktop app via the desktop apps publicly available API. This API only provides the Authorization Code Grant path for authentication, which would require me to either:
somehow securely store the client secret in the app
Implement PKCE & Implicit auth endpoints in my webserver as a pass-through to the API
Have my own auth system (via auth0 or equivalent), which the user then links to their API account
Is 2 possible, or is 3 my only real option?
Yes, 2 is possible, and is much more simple than I imagined. In the following examples Client is the web or mobile app, Server is your server, and API is the api you are trying to reach that only supports Auth Codes
for web (Implicit):
Client sends a standard Implicit request to Server
Server parses this request, then restructures it as an Auth Code request and forwards to API
API validates user login, and sends Auth Code to Server
Server sends Auth Code back to API
API returns access token and refresh
Server returns only access token to Client
for mobile (PKCE):
Client sends a standard PKCE request to Server
Server parses this request, then restructures it as an Auth Code request and forwards to API
API validates user login, and sends Auth Code to Server
Sever sends Auth Code to Client
Client sends Auth Code and Verifier to Client
Server verifies sends Auth Code back to API
API returns access token and refresh
Related
I used Serverless to create API gateway endpoints + lambda functions. I want to secure API gateway endpoints using the access token oAuth. I am trying to provide credentials (sign up and sign in) in my iOS native app. Here are the facts I learned.
I want to secure my API gateway using OAuth and access token.
Because I have already created API gateway endpoints and lambda functions, Signup and Sign in using Amplify is not the best idea. I can't use Amplify's access token in the API gateway because in the Cognito user pool (under App Client Settings) I have selected Authorization Code grant (instead of implicit which is not that secure and client credentials are for the machine to machine) type OAuth flow.
I have in app Sign up and Sign in UI and don't want to use Hosted UI.
I want to authenticate and authorise users of my app.
My question is:- Can I use the Authorization code grant type without using Hosted UI or web browser? i.e. make a rest call with username and password and get the Authorization code. Once I get the Authorization code then make a call to the token endpoint to get the access token. Once I get the access token then call API gate with that access token. All of the above natively without using a browser or hosted UI.
Thank you very much in advance.
I am trying to write an application that:
In a browser, authenticates a user with a Google account.
Calls a backend service.
Backend access user's drive (and some other things) and then returns JSON.
Frontend: copied some example from the web, can authenticate without issues.
Backend: Node.js/Passport.js. Copied the code from an example, can authenticate.
But how do I authenticate a user in the browser and then do an API call so the API may access the Google Drive? What is the expected flow?
A. Web app authenticates the users then passes id_token to the server?
Can't find how to implement this on a server...
or:
B. Server sends app to, say, /auth/google/ on the same server, then app gets a token from server?
Think of OAuth2 as a permission delegation protocol - user (Resource owner) authenticates and gives a consent to passing an access token (or some other tokens) to the OAuth2 client that initiated the process. When the client receives the access token, it can act on behalf of he user and access resources on a resource server (Google Drive).
So if your backend wants to access Google Drive, the cleanest way would be to make your backend an OAuth2 client, that redirects a user to Google auth server and then receives an auth code. The client must ask for scopes that will allow it to access Google Drive. The auth code can be exchanged for an access token. To access Google Drive, the backend needs to send a valid access token in the Authorization HTTP header of the request.
If you need the tokens on your frontend as well, you can use it as an OAuth2 client and pass them to the backend in an HTTP header.
I am trying to implement the OTP authentication flow with SMS using Auth0 (Passwordless Connections with SMS using Twillio).
We have a mobile app, an API, a database and we use Auth0.
Steps:
The user enters a phone number.
Does the client send directly the phone number to Auth0?
Or Does the client send the phone number to the API which calls Auth0 (Twillio)?
The user receives a code through SMS
Does the client send the code to Auth0?
Or Does the client send the code to the API which then sends it to Auth0?
The user enters the code and receives an access_token, an id_token and a refresh_token
Does Auth0 talk directly to the API and the client separately?
Should the client receives these tokens and send it to the back end?
Or Should the API receives these directly and send back to the client only the id_token?
the user accesses the resource in the database.
Does the id_tokem, access_token and refresh_token need to be saved in the database?
These are a few questions I have but I am more confused about the general authentication flow with OTP.
The Auth0 helps you to handle authentication process and your API needs to determine what users can and cannot access with each request. This process is known as authorization. In other words authentication starts on the client-side, while authorization starts on the server-side.
AUTHENTICATION (client)
In your example, client sends directly the phone number to Auth0, Auth0 (Twillio behind the scene) sends back the code.
Client sends back the credentials(phone number and code) to Auth0 that validates them. Once the code is successful, Auth0 encapsulates access information in something called an access token (JWT- JSON Web Token) and identity information in something called an ID token. More about tokens here https://auth0.com/docs/tokens
The mobile application stores the access token and refresh token locally.
AUTHORIZATION (backend)
When the user needs to make a request to a protected API endpoint, the client application must send the access token with the request for the API to then carry out the authorization process. The access_token must be in the authorization header of every request it makes to protected endpoints.
The server validates the access token. If access_token is not valid, use the refresh token to obtain additional access tokens. If valid, the server determines if the token bearer can access the requested endpoint using information within the token.
You server (point 3 in your question) needs few things to start authorization process. You will have to validate the access token using JWT Strategy. If you are using nodejs, there is a good module called Passport which can help you with that.
To configure JWT Strategy you'll need two values from Auth0: an Auth0 Issuer URL and an AuthO Audience. You will get these values by creating api in Auth0 dashboard.
That means Passport validation is all handled by Auth0 in your created tenant (api) in Auth0 dashboard. Auth0 determined the identity of the logged-in user and then passes data about the user within payload object which you can access throughout the request-response cycle through controllers and middleware.
Your protected endpoints e.g /account automatically invokes your JwtStrategy configuration logic and blocks request if the access_token is not valid.
This article helped me a lot to understand OAuth flow which I quoted here a lot :) https://auth0.com/blog/developing-a-secure-api-with-nestjs-getting-started/
For this flow, the user (resource owner) starts in the UI of the API Provider (resource server). The aim is to transfer the user to an oauth client UI where the client app will be able to call APIs in the originating resource server. Note the client app is likely to be closely affiliated with the API Provider (e.g. a cloud service that has the same owner as the API Provider). An option is to send the user to the client which then initiates the usual auth code flow process, but it seems that this could be streamlined by just redirecting to the redirect_uri from the resource server to begin with. Probably best shown by a comparison of the two flow:
Standard OIDC OAuth SSO-type flow:
1) User in client UI.
2) Client directs user to API Provider (auth server).
3) User log-in in to auth server.
4) Authorize client app (/authorize).
5) Redirect to client providing auth code to redirect_uri for client.
6) Client uses auth code to obtain access_token and id_token (/token).
Abbreviated flow:
1) User is in API Provider UI.
2) User does activity which requires handoff to client.
3) Authorize client app (/authorize).
3) Redirect to client providing auth code to redirect_uri for client.
5) Client uses auth code to obtain access_token and id_token. (/token)
Note steps 3 - 5 in abbreviated flow correspond to steps 4 - 6 in standard flow. Since the user starts in the API+Identity Provider, it seems unnecessary to send user to third party so that they can start the flow.
I am wondering what pitfalls there are with the abbreviated flow - for example, there is no state parameter from the client, but the process is started by the API Provider, so I am not sure that there needs to be. Is there a more suitable flow to use than the abbreviated flow described above to hand off to a client app?
We are trying get a SaaS product to authenticate against our AD FS 4.0 services running on Windows Server 2016.
The web application is setup for SSO using JWT and allows us to setup a Shared Secret, Login URL and Logout URL
I got the app to redirect to the AD FS login screen https://hostname/adfs/oauth2/authorize and authenticate against active directory. From there it returns a code value that I know needs to go to https://hostname//adfs/oauth/token but here I'm stuck.
Do I need to build a web service that receives the code from the authorize endpoint, posts it to the token endpoint, and then redirect back to the web app with the JWT? Or can AD FS do this on it's own if I configure it correctly?
What I want is for the web app to redirect to the AD FS login screen (done), AD FS to authenticate against AD (done) and then (do magic) and redirect back to the web app with the JWT.
EDIT:
The following is what I want with Server 2016 AD FS 4.0. Will I need to create my own ADFS/AUTHORIZE->code->ADFS/TOKEN->jwt->Application URL handling service?
https://support.zendesk.com/hc/en-us/articles/203663816-Setting-up-single-sign-on-with-JWT-JSON-Web-Token-
UPDATE:
It does appear you have to have control over the client application, which is not the case when you're using a 3rd party SaaS. Therefore we need to implement a myapi such that.
SaaS redirects to /adfs/oauth2/authorize
AD FS redirects to /myapi/?code=ab2..3cf
myapi posts code to /adfs/oauth2/token
AD FS response contains JWT
myapi redirects to SaaS with /?jwt=token
This flow is called Authorisation Code Grant.
Good diagram here.
Get the code, send it to the /token endpoint, get the access token, send it to the API in the Authorisation header.
If the SaaS product has an OpenID Connect stack, it should do this automatically. The SaaS product needs to drive the flow.
Update:
The only thing you need to do with ADFS is configure it. No programming required.
You need to code the client side.
Client sends to /authorize endpoint.
ADFS responds with code.
Client sends code to /token endpoint.
ADFS responds with token.
Client sends token to API.