How freeradius responds in json format to the request to authorize

Fiorella De Luca deluca_fiorella at
Wed Jul 26 20:46:55 CEST 2017

Regarding checks like bandwidth limits and session time limit, when authorizing through a REST API, I guess we can do these checks in the authorization phase via the REST API too and return an appropiate response accordingly, is this correct?

check the user exists, check password matches, check user has not exhausted their allocated daily bandwidth.

If it's not correct, what's the current best practice in this case?

Thank you for the help! 

    Il Lunedì 24 Luglio 2017 15:48, Arran Cudbard-Bell <a.cudbardb at> ha scritto:

> I've tried your suggestion and it worked!


> I wanted to ask you: are there any publicly available examples of implementations using authorize, authenticate, accounting, postauth (and any other operation) with a REST API?

No, unfortunately not.  If you've got some specific scenarios I can add some examples to

> Another question: If we perform the username & password check in authorize, I suppose there's not much we will need to do in authenticate, correct?

For PAP (Plaintext auth) that's correct.  When you have more complex authentication mechanisms like EAP-PEAP, EAP-TTLS, MSCHAPv2, then the authentication flow is different.  For those methods, you generally need to retrieve the "known good" password via the REST interface, then call the appropriate module in authenticate to actually do something with it.

Could you do this with pap too if you're interested to see how it works.

authorize {

authenticate {

Then your JSON would be:

    control:Cleartext-Password := "<users password>"

You can also return hashed passwords.  The attributes that hold them are in dictionary.freeradius.internal (

Search for -Password.

Note: Only Cleartext-Password will work for all authentication mechanisms.

> Thank you!

No problem.



More information about the Freeradius-Users mailing list