We are trying FusionAuth & looking to have a single step flow for Sign up + Sign In.
After user signs up, we want to show/land him directly to our application's dashboard page (without showing him login page in between the flow). The authentication should happen but internally i.e we are expecting OAuth2 standard IdToken in response to "WebApplication" so that web application can use IdToken to allow user to application.
Please note that we don't want to use approaches where we need to pass Username/password to our web application, don't want to handle user credentials. Also that we dont want to use Authentication Tokens returned in Registration flow because AuthenticationTokens are not that secure, looking to use OAuth2 based IdToken instead.
I have came across this post "https://fusionauth.io/community/forum/topic/165/taking-a-user-directly-to-the-registration-page/3" and tried following request, but it is showing Login page instead of registration.
/oauth2/register?client_id=<Configured_client_id>&redirect_uri=<Configured_redirect_uri>&response_type=code
(I have not used CSRF parameter though)
Please can you suggest why its showing Login Page?
You should be able to have a user register and be sent directly to your application, as long as you set the correct redirect_uri and put that on the registration URL:
https://local.fusionauth.io/oauth2/register?client_id=c50329fa-93e5-4618-8d9f-73d0ab069a23&response_type=code&redirect_uri=https%3A%2F%2Fapp.example.com%2F
The application will then receive a code that can be exchanged for an access token. You can call the userinfo endpoint with that token and get user information like email address, etc.
What you won't get that it seems like you might want is an id token. For that you'll have to send the user through the login process with a scope of profile. However, you could mind your own 'id token'-lite using the values from the userinfo endpoint and the JWT vending: https://fusionauth.io/docs/v1/tech/apis/jwt/#vend-a-jwt
Related
I'm working on a REST API and a web application that will work off said REST API. The REST API implements a stateful token-based authentication pattern. Ultimately, allowing users to exchange their user credentials for a time-limited authentication token that identifies who they are.
So for example, a request such as:
POST: http://localhost:4000/api/v1/tokens/authentication
REQUEST BODY: {"email": "my_email_address", password": "my_password"}
would yield a response like:
"authentication_token": {
"token": "GAHZQS3IEIE6ELF7IHC6GK7M5Y",
"expiry": "2022-07-19T02:49:09.4194657+01:00"
}
If the user credentials that the user entered were incorrect, the user would not receive the authentication token.
The user needs to include the token in any further requests so that the REST API can identify the user. Some API endpoints are restricted to just logged-in users/users with certain permissions. And the token allows the REST API to know what sort of user it's dealing with. The token corresponds to a user id.
There will be a separate server from the REST API server serving the web application pages. But the pages will be populated with data from the REST API via the javascript fetch API.
I am happy with the REST API authentication. But I also need to restrict access to the web application pages based on if the user has logged in or not.
I want to leverage the existing REST API authentication but have never done something like this before so would very much appreciate any input you have.
Currently, I'm thinking of doing something like what's listed below. Do ye see any problems with it?
User accesses login page, enters credentials, and clicks 'login' button.
On clicking the 'login' button a request to the REST API is made:
POST: http://localhost:4000/api/v1/tokens/authentication
REQUEST BODY: {"email": "my_email_address", password": "my_password"}
If the credentials are correct, a token is returned, such as:
"authentication_token": {
"token": "GAHZQS3IEIE6ELF7IHC6GK7M5Y",
"expiry": "2022-07-19T02:49:09.4194657+01:00"
}
This token is added to a cookie for later use. i.e for when making another request to the REST API via the fetch API.
I'm thinking of adding another REST API endpoint that will simply validate a token i.e state whether or not the passed token is still valid and that the user is still logged in.
The webpage server can then call this endpoint to ensure the token is valid before showing a user a page that is restricted to just logged-in users.
Or maybe, instead of a validate token API endpoint, I should have a 'get user by token' endpoint. That will return user data if the token is valid. That way the webpage server could also get to know the type of user account that is associated with that user and could then also restrict pages based on the user type. It might also come in use for populating pages since nearly all pages will contain some user info e.g a profile image.
I'm sure I am missing something here but...
I have an angular application that allows users to fill out forms. The application calls a backend NODEJS service that has a responsibility of building the HTML envelope and document to sign. This back-end service does not have access to a browser.
I have 2 options for flow:
User fills out form -> clicks sign button -> back-end service called to gather the url for the user to redirect to in order to get a code back (consent) -> USER DOES NOT LOGIN TO DOCUSIGN -> redirect back to application -> get token with users code -> prepare envelope on BEHALF of the user -> send application the ceremony URL -> user redirects to ceremony -> signs document -> redirect back to application.
*User fills out form -> clicks sign button -> back-end service called to create envelope and tell DOCUSIGN to send an EMAIL to the user which I don't want to sign up for DOCUSIGN. (Effectively removing the need for them to create an account with DOCUSIGN because I am sending an email and they can authenticate him by knowing he is coming from his own email). -> user signs document through email -> (Would be nice for application to get redirected back to but not necessary)
All examples and chats I have seen discuss only having to login one time. Well in flow 1, I don't want the USER, signing the document, to login or have to make an account for this one signing. And in flow 2, I can't seem to grasp how to keep the back-end service authenticated if it is a BACK-END service. It's headless. No Browser.
These guys are so large that I figure it's something I'm not grasping here.
I understand to impersonate the user, I would need his consent. And possibly... because they don't KNOW the user without him signing up for an account to verify his email, they can't offer consent to a user they can't verify email with. So if that is the case, I would want to authenticate my BACK-END user to send emails so they can just click the email, it MIGHT verify in DOCUSIGN without having to sign up for account, and offer the contract to the user to sign on the spot from the email WITHOUT asking for credentials or NEW account.
If you are going to answer this with a link back to DOCUSIGN authentication examples. Or suggest use a JWT to authenticate from BACK-END services... please explain in detail the steps to authenticate my BACK-END user and keep him authenticated without using a web-browser or how to use the users consent from a redirect from DOCUSIGN without the user having to EVER create an account.
I have tried sending the user to the redirect URL with success if they already have their credentials cached in browser or already have a DOCUSIGN user. The flow works fine there. I get the users code, exchange it for token, create envelope, redirect user to ceremony, redirect back to application after signing complete.
I have read a bunch of articles that all point back to DOCUSIGN help with authenticating 1 of 3 ways with a browser. I need no browser login, or a better understanding of how to avoid the user creating a DOCUSIGN account.
Thank you so much!
Signer, user that signs, does NOT need to have a DocuSign account. They do not need to log in to DocuSign in order to sign. They can sign via email or embedded in your app, but they do NOT need to have an account or log in.
Your app's back end needs an access token to make API calls. This doesn't change the headless nature or the fact that it's back end. A token is a long string that your app uses to authenticate. This authentication is tied to a user in DocuSign that has an account. That is NOT the user that signs, but the user that make the API call. You have to have a user that makes an API call.
You can get a token using JWT authentication and your back end can generate it using the Node.js SDK (npm package) without the need for UI or for anyone to log in.
I want to make a website which users can see their posted pictures on the page.
I have signed up for facebook API and have an app id and app secret.
https://graph.facebook.com/oauth/access_token?client_id={#}&client_secret={#}&grant_type=client_credentials
I send users to the oauth to get the user's access token but I don't know what to do next.
https://graph.facebook.com/v3.0/me?fields=id,name,posts&access_token={#}
I thought this would work but I had the error below
"An active access token must be used to query information about the current user.",
The URL you are using to get the Access Token is actually an App Token API.
To generate the Access Token Please replace
https://graph.facebook.com/oauth/access_token?client_id={#}&client_secret={#}&grant_type=client_credentials
with
https://www.facebook.com/v3.0/dialog/oauth?response_type=token&client_id={#id}&redirect_uri={#}&scope=publish_pages
add a redirection url here where the token is published.
OR
better option is to use the login button mentioned here.
https://developers.facebook.com/docs/facebook-login/web/login-button
Also you can read here about all Access Tokens
https://developers.facebook.com/docs/facebook-login/access-tokens/
I am trying to implement a login for my mobile app to my backend. I previously used to use a method that required hashing on mobile site and backend site. The password would be hashed saved on the mobile site and be included in the hash. If hashes on mobile side and backend side would be equal, the request would be valid.
However I wanted to add Facebook login to my login system so I kinda find out it was not gonna work the way I had built it before. I came to the conclusion that I probably have to change the entire method to token login.
What I have currently functioning is Facebook button on mobile side, this creates for me a Facebook userid and Facebook access token. I send both these values to my backend and use a Facebook graph call to retrieve the facebookid from the access token. if both the Facebook userids are equal. I either register the user or log him in.
This is where I get stuck. I now want to generate my own token to send back to the mobile side, because I have custom login (email+password) (Facebook is just an option). So I think using my own auth token for both ways is the best.
I have a few questions about this token:
What should the token exist of?
Do I need to save this token on the mobile (not hashed?)
What is the best way to built in expiring time and automatic refresh token
What I can't really understand is the security of this authentication method. Sending a token over a request that gives you access to user information is just as bad as a plain password I think? Is SSL connection simply enough?
I understand these are a lot of question in one but I hope someone can give me a clear explanation.
Thank you
You can try JWT (JSON web token), it's really simple. The idea its, when you do the login, the servers return you the JWT and you simply have to save it in your mobile app. Then you have to pass it as a header (assuming you are developing for Android):
request = new HttpGet();
request.addHeader("Authorization", "Bearer " + Global.loginData.jwt);
In the facebook authentication guide, i am suppose to:
Get the user to authorize my
application, by redirecting them to
authorize uri.
Get my access token
from facebook by hitting the
/outh/accesstoken uri.
Lets just say, that for whatever reason, this token is no longer valid. Do i need to perform step #1, or can i hit the /outh/accesstoken uri again?
OAuth 2.0 allows for "refresh tokens" which will do exactly what you want (hit the access token endpoint for a new token). However, Facebook does not support them.
If you want access after the user initially signed in, then you have three choices:
1/ Use the FB JavaScript library to request access in an iframe. It's not using OAuth (yet) but it will do it with minimal user disruption.
2/ Reirect the user to the OAuth endpoint again. If they have already authorized the requested scopes, then it will direct back immediately.
3/ Ask for the "offline_access" extended permission. This should only be used rarely.
If the token is no longer valid, you have to get a new one.