Return to Answer

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication.
  This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.  

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.  

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience).
  If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)

Typically, the standard way to implement proxy authentication is, surprisingly, Proxy Authentication. 
This is a set of matching response and request headers, that together implement authentication that is required between the user and the proxy.

This is commonly used with transparent proxies, and is well supported in both browsers and proxies. Some proxies do implement this differently (e.g. how the credentials are verified), but in most cases this is the much preferred solution. There are very few drawbacks to this solution, and alternate solutions that break standard HTTP, such as BlueCoat, have quite a few issues.

Now, you do mention that your proxy will be implementing a captive portal, but you did not mention why. If it is just to implement the authentication form, thinking that there is no built-in solution, I would recommend you change your solution, use standard proxies, and just define required authentication. Building your own captive portal is just way too tricky, and will likely open you up to a whole slew of vulnerabilities (from experience). 
If there is some other reason to build the captive portal - random signups, payment options, crazy fun, etc - perhaps elaborate, and we can deal with them. Otherwise it does look like an XY problem (where you assume a solution and ask about that, instead of asking about your actual problem...)