I am developing an iPhone application to demonstrate the MFA using sms factor with MFA APIs for POC. I am using the authorisation flow for getting my access token (where I get a authorisation code and redeem it for an access token)earlier to MFA implementation. From the documentation, I found out that I need an MFA_token to work with MFA APIs. I added few changes with my existing authorisation process.
I am getting an MFA Token by doing the following steps:
Added scope enroll read:authenticators to authorisation endpoint( i.e. “https://<my_domain>/authorize”)
Added an audience:
https://<my_domain>/mfa to the authorisation endpoint
Then I make a post request to token endpoint with authorization code to get the mfa_token.
The only changes I can observe is now the access token(which I presume to be the mfa_token) is in jwt format with expire time 600 sec. By using this access token(=mfa_token)
I built a custom pages for my user for enrollment and challenging the user via sms.
I am able to enroll user, confirm enrollment using this access token.
But when I challenge an user using this access token I get the following error after https://YOUR_DOMAIN/mfa/challenge call.
{
“error”: “invalid_grant”,
“error_description”: “Malformed mfa_token”
}
Can anyone please say me where I am going wrong?
Is the access token same as the MFA_Token in my case?
Thanks in Advance!
I think the access_token only serves as mfa_token during OOB/device registration. Thenafter, the user will get an mfa_token during auth, which is passed for MFA/OTP challenges
https://auth0.com/docs/login/mfa/ropg-mfa/manage-authenticator-factors-mfa-api#resource-owner-password-grant
Related
I'm trying to set up Google OAuth2.0 from this guide and I have everything set up and running. I can get the authorization code, the access_token, and the refresh_token to show up in my console.log's. My question is which one of these tokens can I use to properly identify and log in a user to my backend?
In a normal scenario, a user would enter a username & password and that would uniquely identify them. However in the Google OAuth2.0 case, it seems the authorization code, the access_token, and the refresh_token all cannot be used to properly identify and log someone in. Is this understanding correct?
I read a similar post but it doesn't seem to provide a very recent answer that also securely identifies the logged in user.
If I cannot use any of the above mentioned tokens to securely identify and log in a user, is it even possible? How come I see other websites and apps use "sign in with Google" and "sign in with Facebook"?
Another solution I read in a different StackOverflow post said to just get the account ID and use that as an identifier. Isn't that insecure? Can't someone guess the account ID? Also this would be assuming these account IDs are private.
My question is which one of these tokens can I use to properly identify and log in a user to my backend?
the id token from open id connect.
explanation
You are confusing authorization and authentication.
Oauth2 a user to grant and authorize your application access to their data the access token gives you access to their data for a limited time (1 hour). If the user is off line you can use the refresh token to request a new access token. None of theses will tell you that a user is behind the calls.
open id connect allows you to authenticate a user logging in will return an id token
Id token verification
After you receive the ID token by HTTPS POST, you must verify the integrity of the token. Verify the integrity of the ID token
I have been looking for answer of implementing ember-simple-auth (oauth2-password-grant) for days without luck. I use firebase to sign up users, which is successful. However on the log in page, the action of this.get('session').authenticate('authenticator:oauth2', credentials) seems to cause a json error (SyntaxError: Unexpected token < in JSON at position 0).
So my first question is, in theory, how does this authentication check if the user's email/password is correct? Meaning, in which file is the "answer" located? Am I supposed to define a token? If yes, I already tried "serverTokenEndpoint: 'http://localhost:4200/' or serverTokenEndpoint: 'http://localhost:4200/token" and nothing works. Thanks.
Ember simple auth sends login request to API(in your case Firebase). If entered credentials are valid your API will authenticate user, create and save auth token. Authenticated user with created token will be sent to Ember and token will be saved in local storage by Ember simple auth. Every subsequent request from Ember after login needs to include that token in its header and API will authenticate your request based on that token(comparing token from Ember with the one saved in API).
We have an Instagram client id and client secret, and already have gone through the documentation of generating access tokens which requires redirect url.
Note that we also have disabled the implicit OAuth flow.
Now we already have generated the access token using URL below (for authenticated user, it returns the access token appended in the response URL)
https://api.instagram.com/oauth/authorize/?client_id={client_Id}&redirect_uri={redirect_url}&response_type=token&scope=public_content
Can this token be stored in the database / configuration files and re-used for any new Instagram API requests? e.g.
https://api.instagram.com/v1/users/{user_id}/media/recent/?access_token={reusable_access_token}
Based on the official documentation, we understand that the access token can become invalid at any point of time, we would like to know if there are any specific scenarios which leads to invalidation of the access token?
What would be the best way to generate token once and use it for each API request? We definitely do not want users to enter credentials manually to generate tokens.
Unfortunately at that point it's not possible:/ Instagram doesn't provide refreshing access token in the background.
User needs to login with their credentials, so you can obtain new access token. Some kind of workaround (not nice, but it's working) is to watch for error type OAuthAccessTokenException and notify the user via e-mail about such fact. He will have to login once more, so you can get fresh and working access token.
Also, please keep in mind that access tokens has a pretty long life span. It doesn't expire after a day or two, unless Instagram API has some issues (like just now OAuth - unable to exchange code to access token for some users).
Otherwise it works really well.
However it would be super nice if Instagram could add to their API renewal option in the background for access tokens for users that autorised your app, but their token expired:)
I have implemented the Token Authentication according to the django rest framework Docs.
Form what I read, the Token Authentication of DRF is quite simple - one token per user, the token doesn't expire and is valid for use always (am I right?).
I understand that there are better practices out there, but for now the DRF token authentication is fine for me.
my question is- what is the best practice for logout with the normal DRF token authentication?
I mean, when the user logs out, should I delete the token from the client side? and then on login get the token again? should I delete the token and generate a new one?
Anyone with experience with this?
Here's a simple view that I'm using to log out:
from rest_framework import status
from rest_framework.response import Response
from rest_framework.views import APIView
class Logout(APIView):
def get(self, request, format=None):
# simply delete the token to force a login
request.user.auth_token.delete()
return Response(status=status.HTTP_200_OK)
Then add it to your urls.py:
urlpatterns = [
...
url(r'^logout/', Logout.as_view()),
]
WHOLE IDEA OF TOKEN AUTHENTICATION:
Normally in authentication services, there is a lifetime associated with a token. After a specific time, the token will get expired. Here, we get an access token which has an expiry time sent along with it by the server. Now the client needs to send this token everytime in the request header so that the server can identify who the user is. Either we can keep track of when it expires or we can just keep using it until we get an INVALID_TOKEN error. In that case we would have to again get the token from the server.
The lifetime of the access_token is independent of the login session of a user who grants access to a client. OAuth2,lets say, has no concept of a user login or logout, or a session. The token is just used to identify the user if he is who he says he is.
The token is unique for a user and client. You may save it to cookies to enable something like remember me but on the server you don't need to delete it. Whenever the token expires, the client need to send a request to the server to obtain the token again.
Token Expiry in DRF Token Authetication:
Currently, DRF Token authentication does not support this functionality. You would have to implement it yourself or use a third party package which provides this functionality. It should check for token expiry and raise an exception if the token has expired.
To implement it yourself, you can subclass from the DRF Token Authentication class and add your logic.
You can even use a third-party package django-rest-framework-expiring-tokens.
Some References:
1. Token Authentication for RESTful API: should the token be periodically changed?
2. How to Logout of an Application Where I Used OAuth2 To Login With Google?
It sounds like SessionAuthentication is what you are really looking. You can start(login) a session via BasicAuthentication or TokenAuthentication. Then use sessionid as your "token" for the rest of api calls. The "token" expires when you logout or exceed certain timing.
If you run into csrftoken issue using session authentication, this could be a very helpful.
I am building an integration component using a graphical framework who has a pre-build OAuth2 connector.
This framework required following fields for OAuth v2:
Grant type
Scope
Auth Server URL
Client Id
Client Secret
Access Token
Refresh token
I need to get data from Google Analytics API, so I went to Google Dev Console
(https://console.developers.google.com/project/927890000889/apiui/credential). I generated a 'Client ID for web application'. From the parameter of this object I was able to fill some of the parameters above
Grant type : 'authorisation_code'
Client Id : 'RANDOMCHARSam5o37nsiu730d.apps.googleusercontent.com'
Client Secret : 'RANDOMCHARSiSwBA5OH5qYLUa'
Then using Google Oauth Playground (https://developers.google.com/oauthplayground) I was able to fill the missing bits
Scope : 'https://www.googleapis.com/oauth/analytics'
Auth Server URL : 'https://accounts.google.com/o/oauth2/auth'
Access Token : 'RANDOMCHARSQAQv4HRF5-JsQEzUS61lj2YremyCocv0PQ4-agpzJe'
Refresh token : 'RANDOMCHARSLPJnL4FPaDc2KP6V8kCzjjHO2Kj4Np_3X0'
Everything works fine, I am authorised to access and I get data from Google Analytics, but just for a while, after few minutes if I retry I receive an authorisation failure error.
I believe that the problem is related to the expiration of the Access Token, but I don't know how to solve that.
Worth to mention that this activity it's batch (no human interaction), so nobody can request a new access token.
The integration framework is not extensible (I cannot write code to renew the code) so I believe there's a way to get a access token that never expire or some other mechanism to achieve the same result.
Bottom line, I am not sure if I approached the requirement correctly since the beginning (Client ID for web application).
Any help is much appreciated,
Giovanni
Access tokens typically expire after 60 minutes. If you have a refresh token you can use the refresh token to get a new (valid) access token.
This doc explains how to do that:
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
To answer your overarching question, yes, you are approaching everything correctly. All you need to do is handle the case where the access token has expired by refreshing it. Also, when you originally requested the access token the response should tell you how long it's valid for, so you should only refresh that token if it's expired.
You can use Refresh tokens to make it more long used.
The Google Auth server issued Refresh tokens never expire,
A token might stop working for one of these reasons:
The user has revoked access.
The token has not been used for six months.
The user changed passwords and the token contains Gmail scopes.
The user account has exceeded a certain number of token requests. There is currently a limit of 50 refresh tokens per user account
per client.If the limit is reached, creating a new token automatically invalidates the oldest token without warning.
This limit does not apply to service accounts.
from: https://developers.google.com/identity/protocols/OAuth2